Les experts savent comment rédiger des requêtes performantes. Bien que l'expérience mûrisse la sagesse, il y a certaines choses que l'on doit comprendre au moins pour commencer. Par exemple, vous devez comprendre les considérations clés de la conception des requêtes ; comment une requête fonctionne en interne, où elle échoue, modèles d'optimisation, etc. Dans cet article, je fournirai quelques points d'optimisation sur lesquels réfléchir lors de la conception d'une requête dans MySQL.
Pourquoi certaines requêtes sont-elles lentes ?
Un problème courant avec les requêtes SQL est que plus de données sont récupérées que ce qui est réellement nécessaire. Bien sûr, il y a des requêtes qui passent au crible beaucoup de données et nous ne pouvons pas y faire grand-chose, mais elles ne sont pas courantes. Dans la plupart des cas, c'est une mauvaise conception des requêtes qui entraîne de mauvaises performances des requêtes. Après chaque conception de requête, vous devez faire une introspection sur quelques aspects comme ce qui pourrait se passer après le déclenchement de la requête :
- La requête SQL accédera-t-elle à trop de colonnes ou de lignes ?
- Le serveur MySQL analysera-t-il trop de lignes pour récupérer le résultat souhaité ?
Certaines requêtes obligent le serveur MySQL à analyser trop de données, mais les lancent au fur et à mesure qu'il passe au crible. Il s'agit d'un travail supplémentaire pour le serveur en termes de nombreux aspects tels que la surcharge du réseau, une trop grande consommation de mémoire ou une trop grande utilisation des ressources CPU sur le serveur. La conséquence est un ralentissement des performances.
Il y a des situations où vous ne pourrez peut-être pas beaucoup aider lors de sa conception, mais il y a une situation où si vous faites attention et estimez la conséquence et l'introspection, alors une mauvaise requête peut au moins être corrigée sinon meilleure.
Erreurs typiques et leurs solutions
Il y a pas mal d'erreurs courantes souvent commises lors de la rédaction d'une requête. En voici quelques-uns. Vous pouvez trouver quelques autres réflexions sur la même ligne. Voici les raisons de la lenteur des performances des requêtes avec des solutions possibles.
Trop de lignes
L'erreur est souvent commise en écrivant une requête qui récupère des données et en supposant que MySQL fournira un résultat à la demande tout en négligeant la quantité de traitement nécessaire pour renvoyer l'ensemble de résultats complet. Supposons qu'une instruction SELECT soit déclenchée pour récupérer 100 détails de produits pour un site de commerce électronique alors que seulement 10 d'entre eux doivent être affichés en premier. Vous pourriez penser que MySQL ne récupère que 10 lignes et arrête d'exécuter la requête. Mais non. Ce que MySQL fait, c'est générer le jeu de résultats complet et alimenter le client. La bibliothèque cliente reçoit l'ensemble complet et en rejette la majeure partie et ne conserve que 10 exemplaires qu'elle recherche. Cela gaspille clairement beaucoup de ressources.
Cependant, dans une telle situation, vous pouvez fournir une solution en utilisant la clause LIMIT avec la requête.
SELECT col1, col2,... FROM table_name LIMIT [offset,] count;
La clause LIMIT accepte un ou deux paramètres. Le premier spécifie le décalage et le second spécifie le nombre. Si un seul paramètre est spécifié, il indique le nombre de lignes depuis le début du jeu de résultats.
Par exemple, pour sélectionner 10 lignes du tableau, vous pouvez écrire :
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10;
Et pour sélectionner les 10 lignes suivantes, à partir de 11 enregistrements, vous pouvez écrire :
SELECT e.emp_name, e.phone, e.email FROM employee e LIMIT 10, 10;
Trop de colonnes
Regardez toujours la requête :SELECT * avec méfiance. Cette requête renvoie toutes les colonnes et vous n'avez probablement besoin que de certaines d'entre elles. Le plus grand inconvénient de la récupération de toutes les colonnes est qu'elle empêche l'optimisation en entravant l'utilisation des index, demande trop d'E/S, de mémoire et de ressources CPU au serveur.
Comprenez qu'une telle requête universelle récupérant toutes les colonnes peut être inutile. Certains disent qu'ils sont utiles car ils permettent au développeur d'utiliser le même morceau de code à plusieurs endroits. C'est bien si le coût impliqué est limité dans la considération. Parfois, la mise en cache des données récupérées aide dans ce contexte. Mais soyez prudent, tirer parti des performances est un travail élégant et un tel luxe n'a peut-être pas sa place pour les performances.
La règle d'or consiste à éviter de telles requêtes universelles ou à limiter autant que possible le nombre de colonnes extraites.
Trop d'analyse de données
Les requêtes renvoient le résultat souhaité qui est correct, mais parfois ces requêtes sont écrites de telle manière que lors du traitement, il faut examiner trop de données avant de générer des résultats. Par conséquent, dans MySQL, vous devez mesurer selon les métriques de coût suivantes :
- Temps d'exécution
- Lignes examinées
- Colonnes examinées
Vous pouvez obtenir une estimation approximative du coût des requêtes à partir de ces métriques. Ceux-ci reflètent la quantité d'accès aux données par MySQL en interne pour traiter la requête et la vitesse d'exécution de la requête. Étant donné que ces métriques sont enregistrées dans le journal des requêtes lentes, il est judicieux d'enquêter et de trouver des requêtes qui analysent trop de données pour renvoyer le résultat. La base de données MySQL enregistre toutes les requêtes qui dépassent un temps d'exécution donné dans le journal des requêtes lentes. C'est l'endroit idéal pour rechercher des requêtes lentes et savoir à quelle fréquence elles le sont.
Un journal des requêtes lentes se trouve généralement dans /var/log/mysql/mysql-slow.log
Notez que vous devrez peut-être définir et activer la journalisation des requêtes lentes dans mysqld.cnf fichier de configuration comme suit.
#slow_query_log = 1 #slow_query_log_file = /var/log/mysql/mysql-slow.log #long_query_time = 2
Avant et avec MySQL 5, il y avait de sérieuses limitations, en particulier le manque de prise en charge de la journalisation fine. Le seul répit consistait à utiliser des correctifs permettant la journalisation. Cependant, la fonctionnalité faisait partie des serveurs MySQL 5.1 et versions ultérieures dans le cadre de sa fonctionnalité principale.
Les requêtes qui prennent trop de temps à s'exécuter ne signifient pas nécessairement qu'il s'agit de mauvaises requêtes. Le journal des requêtes lentes offre simplement la possibilité d'examiner les performances des requêtes et de les améliorer autant que possible.
Restructuration des requêtes
Comme vous avez la possibilité de restructurer les requêtes problématiques, votre objectif principal devrait être de trouver une solution alternative pour obtenir l'effet souhaité. Vous pouvez transformer la requête en sa forme équivalente en gardant à l'esprit l'effet interne dans le serveur MySQL lors du traitement.
Une décision dans la conception des requêtes est de savoir si nous devons privilégier une requête complexe à la place de plusieurs requêtes simples ou vice versa. L'approche conventionnelle de la conception de bases de données consiste à effectuer autant de travaux que possible avec moins de requêtes. La raison en est qu'une requête volumineuse/complexe est plus rentable en termes d'établissement de connexion à la base de données. L'avantage de la réduction des coûts en faveur des requêtes complexes est l'utilisation du réseau, le traitement/l'optimisation des requêtes et l'utilisation des ressources. Mais cette approche traditionnelle ne convient pas à MySQL. MySQL est conçu pour gérer rapidement la connexion et la déconnexion de la base de données. Par conséquent, l'établissement de la connexion, le lancement de nombreuses requêtes plus simples et la fermeture de la connexion semblent plus efficaces. Récupérer des données via plusieurs requêtes simples au lieu d'une seule requête complexe est plus efficace. Notez que la même idée peut ne pas être appliquée avec d'autres bases de données.
Conclusion
Voici quelques conseils rapides pour l'optimisation des requêtes. Comprendre que, connaître les syntaxes SQL, pouvoir créer une requête qui récupère le résultat souhaité ne suffit pas si l'on vise la performance des requêtes. Comprendre ce qui se passe sous les requêtes apparemment simples est essentiel pour en écrire une qui non seulement récupère ce qui est souhaité, mais imprègne l'art de l'optimisation là où tout commence. Les coulisses du traitement des requêtes donnent un indice important pour comprendre les performances des requêtes et cette connaissance est indispensable avant une incursion dans le domaine de l'optimisation des requêtes.
