Tuning de slow queries en MySQL — el workflow EXPLAIN-driven que usamos en bases de cliente

Cada auditoría de MySQL que hacemos saca a la luz el mismo puñado de antipatrones de queries. Las correcciones casi siempre son pequeñas (un índice, una reescritura, un LIMIT), pero encontrarlas a escala es la parte que requiere disciplina. El slow query log es el punto de entrada correcto — pero solo si de verdad lo lees.

Este es el workflow EXPLAIN-driven que usamos para triar slow queries en bases de cliente.

El bucle 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    # ruidoso, off

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

pt-query-digest agrupa las queries por huella y las ordena por tiempo total. Las 10 primeras huellas son casi siempre el 80 % del dolor de la BBDD.

El artículo completo cubre:

• El umbral long_query_time de 0,5 segundos y cuándo bajarlo
• Leer la salida de EXPLAIN ANALYZE (filas examinadas, elección de clave, % filtrado)
• performance_schema.events_statements_summary_by_digest como alternativa en vivo al log
• Los siete antipatrones que seguimos encontrando (wildcards al inicio, OR vs UNION, SELECT *, etc.)
• Diseño de índices — covering indexes, longitud de prefijo en VARCHAR, orden compuesto
• Cuándo arreglar el esquema vs cuándo reescribir la query

Háblanos si tu slow log ha crecido hasta el punto de que nadie lo abre ya.