长事务为什么会导致 MySQL 性能雪崩
长事务本身不直接消耗 CPU，但会持续持有锁、阻止 MVCC 清理、拖慢 purge 线程，最终让整个实例响应变慢甚至卡死。最典型的信号是
SHOW ENGINE INNODB STATUS中看到大量
TRX_WAITING或
purge lag持续上涨。
如何识别正在运行的长事务
MySQL 8.0+ 推荐用
performance_schema查实时活跃事务；5.7 及更早版本依赖
information_schema.INNODB_TRX，但要注意它只显示已开启且未提交的事务，不包含空闲连接中的“假长事务”。
SELECT trx_id, trx_state, trx_started, TIMEDIFF(NOW(), trx_started) AS duration, trx_query FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;
trx_state = 'RUNNING'但
trx_query IS NULL：可能是应用端开启了事务但没执行语句，或网络中断后连接挂起 结果中频繁出现相同
trx_query：大概率是业务逻辑里漏了
COMMIT或异常未回滚 即使
duration不大，若事务内执行了大范围
UPDATE或
DELETE，仍可能造成锁等待链
避免长事务的实操手段
核心原则是「事务粒度与业务边界对齐」，而不是靠超时自动杀——那只是兜底，不是设计。
所有 DML 操作前加SET innodb_lock_wait_timeout = 10（根据业务容忍调整），防止无限等待 应用层用
try/except包裹事务块，确保无论成功失败都显式调用
commit()或
rollback()禁止在事务中做 HTTP 请求、文件读写、循环 sleep 等外部耗时操作 批量更新拆成小事务：比如处理 10 万行，用
WHERE id BETWEEN ? AND ?分页，每 1000 行提交一次 读多写少场景优先用
SELECT ... LOCK IN SHARE MODE替代
SELECT FOR UPDATE，降低锁强度
监控与告警必须覆盖的关键指标
光看
Threads_running或
QPS发现不了长事务问题。真正有效的指标藏在 InnoDB 内部：
Innodb_trx_rseg_history_len：历史列表长度，持续 > 10000 是 purge 延迟明显信号
innodb_max_purge_lag配置值是否被频繁触发（查
SHOW STATUS LIKE 'Innodb_max_purge_lag%） 每分钟扫描
INNODB_TRX表，统计平均
trx_duration并告警 > 30s 的实例 慢日志中出现
Rows_examined极高但执行时间短的事务：说明它在等锁，而非真慢
事务不是越长越“稳”，而是越长越危险。最容易被忽略的是连接池配置——
maxIdleTime设为 0 或极大值，会让空闲事务连接长期不释放，伪装成长事务。
