Lang laufende Transaktionen und History List Length (Purge-Rückstand)
MySQLPerformanceBefehl
-- 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;Was es tut
Zeigt, wie weit Purge im Rückstand ist (History List Length), und die ältesten Transaktionen, die ihn aufhalten: Eigentümer, Alter, geänderte Zeilen und die zuletzt ausgeführte SQL-Anweisung.
Wann einsetzen
Wenn der Undo-Tablespace wächst, dieselben Abfragen mit der Zeit langsamer werden (sie lesen alte Zeilenversionen) oder bei Speicherplatzalarmen.
Vorsicht
Häufigste Ursache ist eine Session in Sleep mit offener Transaktion oder ein unter REPEATABLE READ vergessener Consistent Snapshot (z. B. ein abgebrochener mysqldump / Report). Nach KILL dauert das Rollback so lange, wie es den von der Transaktion geänderten Zeilen entspricht; eine Transaktion mit hohem trx_rows_modified zu beenden bedeutet ein langes, IO-intensives Rollback, und ein Neustart verkürzt es nicht. Undo wird automatisch verkleinert, sobald Purge aufgeholt hat (innodb_undo_log_truncate=ON).
Verwandte Einträge
- Die teuersten Abfragen finden (performance_schema digest)
- Was läuft gerade: aktive Sessions, Latenz, Sperren und Transaktionen (sys.session)
- 'Waiting for table metadata lock' diagnostizieren und den eigentlichen Blocker finden
- InnoDB-Deadlocks analysieren und alle protokollieren
- Kurzzeitig ein vollständiges Slow Log aufzeichnen und mit pt-query-digest analysieren
- Einen schlechten Plan mit EXPLAIN ANALYZE und dem Optimizer Trace untersuchen