Transacciones de larga duración e history list length (retraso de purge)

Comando

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

Qué hace

Muestra cuánto va retrasado el purge (history list length) y las transacciones más antiguas que lo frenan: propietario, antigüedad, filas modificadas y la última SQL que ejecutaron.

Cuándo usarlo

Cuando crece el tablespace de undo, cuando las mismas consultas se vuelven más lentas con el tiempo (recorren versiones antiguas de filas) o ante alertas de espacio en disco.

Precaución

La causa más común es una sesión en Sleep con una transacción abierta, o un snapshot consistente olvidado bajo REPEATABLE READ (p. ej. un mysqldump / informe abandonado). Tras el KILL, el rollback tarda tanto como filas cambió la transacción; matar una transacción con un trx_rows_modified alto implica un rollback largo y pesado en IO, y un reinicio no lo acorta. El undo se trunca automáticamente cuando el purge se pone al día (innodb_undo_log_truncate=ON).