Transactions longues et history list length (retard de purge)

Commande

-- Undo records waiting for purge (millions = trouble)
SELECT NAME, COUNT AS history_list_length
FROM information_schema.INNODB_METRICS WHERE NAME = 'trx_rseg_history_len';

-- Oldest transactions, their owner and last SQL
SELECT trx.trx_id, trx.trx_mysql_thread_id AS conn_id, trx.trx_state,
       TIMESTAMPDIFF(SECOND, trx.trx_started, NOW()) AS age_sec,
       trx.trx_rows_modified, trx.trx_rows_locked, trx.trx_isolation_level,
       p.USER, p.HOST, p.COMMAND, p.TIME AS state_sec,
       LEFT(COALESCE(trx.trx_query, esc.SQL_TEXT), 80) AS current_or_last_sql
FROM information_schema.INNODB_TRX trx
JOIN performance_schema.processlist p ON p.ID = trx.trx_mysql_thread_id
LEFT JOIN performance_schema.threads th ON th.PROCESSLIST_ID = trx.trx_mysql_thread_id
LEFT JOIN performance_schema.events_statements_current esc ON esc.THREAD_ID = th.THREAD_ID
ORDER BY trx.trx_started
LIMIT 10;

Ce que fait la commande

Montre le retard de la purge (history list length) et les transactions les plus anciennes qui la retiennent : propriétaire, âge, lignes modifiées et dernier SQL exécuté.

Quand l'utiliser

Quand le tablespace undo grossit, quand les mêmes requêtes ralentissent avec le temps (elles parcourent d'anciennes versions de lignes) ou sur des alertes d'espace disque.

Attention

La cause la plus fréquente est une session en Sleep avec une transaction ouverte, ou un consistent snapshot oublié sous REPEATABLE READ (par ex. un mysqldump / rapport abandonné). Après KILL, le rollback dure autant que les lignes modifiées par la transaction ; tuer une transaction avec un trx_rows_modified élevé implique un rollback long et lourd en IO, et un redémarrage ne le raccourcit pas. L'undo est tronqué automatiquement une fois la purge rattrapée (innodb_undo_log_truncate=ON).