b) L'analyse post-mortem

L'utilisation d'un site par les utilisateurs ne correspond pas toujours exactement à l'utilisation qui en a été faite par des testeurs. Au final, des requêtes qui semblaient optimisées en recette peuvent ralentir le serveur en production. Pour y remédier, il faut tout d'abord les identifier. C'est l'objet des paramètres long_query_time et log_slow_queries (ce dernier étant désormais remplacé par slow_query_log et slow_query_log_file depuis MySQL 5.1.29). Toutes les requêtes prenant plus de 10 secondes (valeur par défaut de long_query_time) à s'exécuter seront enregistrées dans un fichier de log.

L'utilisation de ces paramètres se fait soit en ligne de commande au lancement du serveur MySQL, soit plus simplement, en ajoutant ces lignes dans le fichier de configuration my.ini (sous Windows) ou my.cnf (sous Unix).

Par exemple :
[mysql]
long_query_time = 5
log_slow_queries = "D:/MySQL-Data/slow_queries.log"

Toute requête qui entre dans ce fichier de log devrait définitivement être améliorée.

D'autres paramètres peuvent être intéressants pour des analyses temporaires :

• log (general_log et general_log_file depuis MySQL 5.1.29) : enregistre toutes les requêtes exécutées. Inutile de dire que cette option peut fortement ralentir le serveur
• log_queries_not_using_indexes (intégré dans log_slow_queries depuis MySQL 5.1.29) : enregistre les requêtes qui n'utilisent pas d'index. Toutes les requêtes concernées ne sont pas forcément mal écrites : par exemple, récupérer l'ensemble des profils d'utilisateurs afin de créer la boîte de sélection du profil d'un nouvel utilisateur fait un full scan d'une table, même s'il s'agit au final d'une table de quatre ou cinq enregistrements.

Si malgré toutes les optimisations réalisées, vos requêtes sont toujours lourdes, alors peut-être s'agit-il plutôt d'un problème de conception : réfléchissez à votre architecture, peut-être que certaines de vos données devraient être pré-calculées et stockées ?