Note de l'auteur :
Récemment, Ghislain (qui gère les serveurs de nexen) m'a rappelé l'existence de SHOW FULL PROCESSLIST, qui est si pratique pour faire afficher la totalité des requêtes SQL en cours, et non pas les premiers caractères. Quand on veut profiler un serveur, et savoir quelles sont les requêtes qui sont si lentes, c'est vraiment essentiel.
Autrement, je recommande souvent 4 étapes pour profiler une requête SQL :
1) L'exécuter manuellement et voir le temps qu'elle prend dans le client MySQL. C'est souvent par cela qu'on commence, vu qu'il faut bien déboguer fonctionnellement la requête avant de la profiler. A ce stade, si le temps de calcul dépasse 0.00s, c'est mauvais. EXPLAIN arrive alors à la rescousse.
2) Après les tests à l'unité, il faut évaluer le comportement avec beaucoup de données. Généralement, un ordre de magnitude de plus que ce qui est attendu est une bonne marque : vous envisagez 1 million de clients ? Créez donc 10 millions de lignes dans la table, et voyez l'impact.
3) Outre les données, il y a bien sûr l'exécution dynamique qui joue aussi : prenez la requête, la bonne quantité de données, et utilisez mysqlslap (livré en standard), mysql super smack ou même votre propre script PHP. Que se passe-t-il quand cette requête est en concurence avec elle-même ?
4) Enfin, il reste à tester au final dans des conditions de concurrence avec d'autres requêtes. Idéalement, un log de requêtes MySQL permet de rejouer des variétés réalistes de requêtes, et de voir comment l'ensemble se comporte.
Cette approche est la plus complète pour vérifier qu'une requête SQL sera viable dans un système en production. Si la 4eme étape est au niveau du luxe, les deux premières devraient être faciles à inclure dans n'importe quel plan de développement : elles identifient 90% des problèmes les plus courants.
- SHOW PROCESSLIST
- mysqlslap
- MySQL SuperSmack
Récemment, Ghislain (qui gère les serveurs de nexen) m'a rappelé l'existence de SHOW FULL PROCESSLIST, qui est si pratique pour faire afficher la totalité des requêtes SQL en cours, et non pas les premiers caractères. Quand on veut profiler un serveur, et savoir quelles sont les requêtes qui sont si lentes, c'est vraiment essentiel.
Autrement, je recommande souvent 4 étapes pour profiler une requête SQL :
1) L'exécuter manuellement et voir le temps qu'elle prend dans le client MySQL. C'est souvent par cela qu'on commence, vu qu'il faut bien déboguer fonctionnellement la requête avant de la profiler. A ce stade, si le temps de calcul dépasse 0.00s, c'est mauvais. EXPLAIN arrive alors à la rescousse.
2) Après les tests à l'unité, il faut évaluer le comportement avec beaucoup de données. Généralement, un ordre de magnitude de plus que ce qui est attendu est une bonne marque : vous envisagez 1 million de clients ? Créez donc 10 millions de lignes dans la table, et voyez l'impact.
3) Outre les données, il y a bien sûr l'exécution dynamique qui joue aussi : prenez la requête, la bonne quantité de données, et utilisez mysqlslap (livré en standard), mysql super smack ou même votre propre script PHP. Que se passe-t-il quand cette requête est en concurence avec elle-même ?
4) Enfin, il reste à tester au final dans des conditions de concurrence avec d'autres requêtes. Idéalement, un log de requêtes MySQL permet de rejouer des variétés réalistes de requêtes, et de voir comment l'ensemble se comporte.
Cette approche est la plus complète pour vérifier qu'une requête SQL sera viable dans un système en production. Si la 4eme étape est au niveau du luxe, les deux premières devraient être faciles à inclure dans n'importe quel plan de développement : elles identifient 90% des problèmes les plus courants.
- SHOW PROCESSLIST
- mysqlslap
- MySQL SuperSmack
-
Auteur
-
Origine
