MySQL长事务有什么危害以及如何排查-mysql教程-PHP中文网

长事务会持续占锁、阻碍undo清理、卡住mvcc快照，导致查询变慢甚至实例雪崩；可通过innodb_trx和performance_schema定位，但需结合状态、sql及应用日志综合判断是否可杀。

mysql长事务有什么危害以及如何排查

长事务不是“慢一点”，而是持续占锁、拖住 undo 清理、卡住 MVCC 快照，轻则让 SELECT 变慢，重则直接拖垮整个实例。

长事务会把数据库拖成什么样

它不报错、不打满 CPU，但会让数据库在你看不见的地方持续恶化：

trx_rows_locked 高意味着锁被长期持有，其他事务排队等锁，innodb_row_lock_waits 指标会明显上升
undo 日志无法 purge，innodb_undo_log_truncated 可能触发，ibdata1 或独立 undo 表空间持续膨胀
innodb_history_list_length 突增（常超 10000），说明 MVCC 版本链失控，简单查询也要遍历大量旧版本
主库 binlog 刷盘延迟，从库 Seconds_Behind_Master 拉高，且 slave_sql_running_state 显示 “Waiting for table metadata lock” 类似卡点
连接池耗尽：一个长事务占一个连接，20 个长事务就能把默认 max_connections=200 的实例压到雪崩边缘

用 `INNODB_TRX` 查当前活跃长事务

这是最直接、无需额外配置的排查方式，适用于所有 MySQL 5.6+ 版本：

SELECT 
  trx_id,
  trx_mysql_thread_id AS thread_id,
  trx_started,
  TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS duration_sec,
  trx_state,
  trx_isolation_level,
  trx_query
FROM information_schema.INNODB_TRX 
WHERE TIMESTAMPDIFF(SECOND, trx_started, NOW()) > 5
ORDER BY duration_sec DESC;

注意几个关键点：

别只看 duration_sec，要结合 trx_state = 'RUNNING' 和 trx_query 判断是否真在执行，还是卡在外部调用（比如 HTTP 请求没返回）
trx_mysql_thread_id 是 kill 的依据，不是 PROCESSLIST_ID；杀之前先 SELECT * FROM information_schema.PROCESSLIST WHERE ID = ? 确认用户和 host
如果 trx_query 为 NULL，说明事务已执行完 SQL，正卡在应用层——这时候 kill 没用，得查应用日志
高并发下建议加 LIMIT 20，避免大结果集拖慢查询本身

用 `performance_schema` 追源头（MySQL 5.7+）

当你要定位是哪个服务、哪台机器、哪段代码发起的长事务时，INNODB_TRX 不够用，必须关联线程和语句历史：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

SELECT 
  p.THREAD_ID,
  p.PROCESSLIST_ID,
  CONCAT(p.PROCESSLIST_USER, '@', p.PROCESSLIST_HOST) AS user_host,
  p.PROCESSLIST_INFO AS current_sql,
  t.TIMER_WAIT / 1000000000 AS trx_duration_sec,
  esh.SQL_TEXT AS last_executed_sql
FROM performance_schema.events_transactions_current t
JOIN performance_schema.threads p ON t.THREAD_ID = p.THREAD_ID
LEFT JOIN performance_schema.events_statements_history esh 
  ON p.THREAD_ID = esh.THREAD_ID AND esh.EVENT_NAME = 'statement/sql/select'
WHERE t.STATE = 'ACTIVE' 
  AND t.TIMER_WAIT > 5000000000
ORDER BY t.TIMER_WAIT DESC
LIMIT 10;

这个查询依赖两个前提：

performance_schema 必须启用：SET GLOBAL performance_schema = ON;
events_statements_history 消费者要打开：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_statements_history';
历史记录默认只保留 10000 条，线上建议提前设大：SET GLOBAL performance_schema_events_statements_history_size = 100000;

如果 SQL_TEXT 为空，大概率是 ORM 自动开启事务后没显式提交，或者用了 START TRANSACTION 但没配对 COMMIT。

容易被忽略的陷阱

排查时最容易掉进这几个坑：

只查 INNODB_TRX 却没看 INNODB_LOCK_WAITS，导致误判“没锁冲突”——其实阻塞链已在形成，只是 victim 还没被选中
监控脚本里用 NOW() 计算时长，但没考虑时区差异，导致告警阈值失效（比如 DB 用 UTC，脚本用本地时区）
看到 trx_state = 'LOCK WAIT' 就以为是死锁，其实可能是单边等待；真正死锁只会在 SHOW ENGINE INNODB STATUS\G 的输出里出现 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: 块
用 KILL 终止事务后，回滚可能持续数分钟——特别是涉及百万级更新的事务，SHOW PROCESSLIST 里状态会变成 Rolling back，此时不能重复 KILL