Tuning des slow queries MySQL — le workflow EXPLAIN-driven que nous utilisons sur les bases clients

Chaque audit MySQL que nous menons fait remonter la même poignée d'antipatterns de requêtes. Les correctifs sont presque toujours petits (un index, une réécriture, un LIMIT), mais les trouver à l'échelle est la part qui demande de la discipline. Le slow query log est le bon point d'entrée — mais seulement si vous le lisez réellement.

Voici le workflow EXPLAIN-driven que nous utilisons pour trier les slow queries sur les bases clients.

La boucle slow query log + pt-query-digest

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5
log_slow_admin_statements = 1
log_queries_not_using_indexes = 0    # bruyant, off

pt-query-digest /var/log/mysql/slow.log > /tmp/digest.txt
head -100 /tmp/digest.txt

pt-query-digest regroupe les requêtes par empreinte et les classe par temps total. Les 10 premières empreintes sont presque toujours 80 % de la douleur de la DB.

L'article complet couvre :

• Le seuil long_query_time de 0,5 seconde et quand le baisser
• Lire la sortie EXPLAIN ANALYZE (lignes examinées, choix de clé, % filtré)
• performance_schema.events_statements_summary_by_digest comme alternative live au log
• Les sept antipatterns que nous trouvons encore (wildcards en tête, OR vs UNION, SELECT *, etc.)
• Design d'index — covering indexes, longueur de préfixe sur VARCHAR, ordre composite
• Quand corriger le schéma vs quand réécrire la requête

Contactez-nous si votre slow log a grandi au point que plus personne ne l'ouvre.