Долгие транзакции и history list length (отставание purge)

Команда

-- 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;

Что делает

Показывает, насколько отстаёт purge (history list length), и самые старые транзакции, которые его сдерживают: владелец, возраст, изменённые строки и последний выполненный SQL.

Когда использовать

Когда растёт undo-табличное пространство, когда одни и те же запросы со временем замедляются (сканируют старые версии строк) или при оповещениях о месте на диске.

Внимание

Самая частая причина — сессия в Sleep с открытой транзакцией или забытый consistent snapshot под REPEATABLE READ (например, брошенный mysqldump / отчёт). После KILL откат длится пропорционально числу изменённых транзакцией строк; завершение транзакции с большим trx_rows_modified означает долгий откат с интенсивным IO, и перезапуск его не сокращает. Undo усекается автоматически, когда purge догоняет (innodb_undo_log_truncate=ON).