Trouver les requêtes les plus coûteuses (digest performance_schema)
MySQLPerformancesCommande
SELECT SCHEMA_NAME AS db,
LEFT(DIGEST_TEXT, 80) AS query,
COUNT_STAR AS calls,
ROUND(SUM_TIMER_WAIT / 1e12, 2) AS total_sec,
ROUND(AVG_TIMER_WAIT / 1e9, 2) AS avg_ms,
ROUND(QUANTILE_95 / 1e9, 2) AS p95_ms,
ROUND(100 * SUM_TIMER_WAIT / SUM(SUM_TIMER_WAIT) OVER (), 1) AS pct_total,
ROUND(SUM_ROWS_EXAMINED / NULLIF(COUNT_STAR, 0)) AS rows_exam_per_call,
ROUND(SUM_ROWS_SENT / NULLIF(COUNT_STAR, 0)) AS rows_sent_per_call,
SUM_NO_INDEX_USED AS no_index,
SUM_CREATED_TMP_DISK_TABLES AS tmp_disk,
LAST_SEEN
FROM performance_schema.events_statements_summary_by_digest
WHERE SCHEMA_NAME IS NOT NULL
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 20;
-- Server-wide top wait events
SELECT events, total, total_latency, avg_latency FROM sys.waits_global_by_latency LIMIT 10;Ce que fait la commande
Classe les requêtes normalisées par temps total avec le nombre d'appels, la latence moyenne et p95, la part du total, les lignes examinées / envoyées par appel, les exécutions sans index et les tables temporaires écrites sur disque. La deuxième requête montre sur quelles attentes (IO, verrous, redo) le temps est passé.
Quand l'utiliser
Premier réflexe quand la charge CPU / IO augmente ou que les utilisateurs signalent que « la base est lente » ; fonctionne même si le slow log est désactivé.
Attention
Les valeurs sont cumulées depuis le dernier redémarrage ou TRUNCATE TABLE performance_schema.events_statements_summary_by_digest ; prenez deux instantanés et calculez la différence pour voir l'activité actuelle. La table est limitée à performance_schema_digests_size lignes ; une fois pleine, les nouvelles requêtes sont agrégées dans une seule ligne avec un DIGEST NULL. DIGEST_TEXT est tronqué à performance_schema_max_digest_length (1024) octets. Les temps sont en picosecondes. Un ratio rows_exam_per_call / rows_sent_per_call élevé est le signe le plus clair d'un index manquant.
Voir aussi
- Ce qui s'exécute en ce moment : sessions actives, latence, verrous et transactions (sys.session)
- Diagnostiquer 'Waiting for table metadata lock' et trouver le vrai bloqueur
- Analyser les interblocages InnoDB et les journaliser tous
- Transactions longues et history list length (retard de purge)
- Capturer un slow log complet de courte durée et l'analyser avec pt-query-digest
- Déboguer un mauvais plan avec EXPLAIN ANALYZE et l'optimizer trace