长事务拖慢MySQL因持续持锁及阻塞MVCC清理，致innodb_history_list_length升高、DML变慢；需查INNODB_TRX计算运行时长并关联SQL定位；应用层须设超时、禁外部耗时操作、启用连接池泄漏检测；服务端应配置锁等待与空闲超时参数。
长事务为什么会让 MySQL 变慢
长事务本身不直接消耗大量 CPU 或磁盘 IO，但它会持续持有锁、阻止 MVCC 清理旧版本（undo log），导致 information_schema.INNODB_TRX 中事务堆积、innodb_history_list_length 持续升高。这会拖慢所有后续的 DML 操作——尤其是 UPDATE/DELETE，因为它们要扫描更长的 undo 链来判断可见性。
如何快速识别正在运行的长事务
别只查 SHOW PROCESSLIST，它看不到已空闲但未提交的事务。真正有效的是：
- 查
information_schema.INNODB_TRX，重点关注TRX_STARTED和TRX_STATE = 'RUNNING'的记录，用UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(TRX_STARTED)算出秒数 - 配合
performance_schema.events_statements_current关联 SQL，确认是不是某个应用连接卡在了COMMIT前 - 注意：
TRX_MYSQL_THREAD_ID可以关联到PROCESSLIST.ID，但线程可能已断开，此时TRX_STATE仍为RUNNING
应用层必须做的三件事
数据库配置再严，也拦不住应用端的“忘提交”。关键动作得落在代码里：
- 所有事务块必须有明确超时控制：Java 用
@Transactional(timeout = 30)，Python SQLAlchemy 设置execution_options={'timeout': 30} - 禁止在事务内做 HTTP 调用、文件读写、sleep 等外部耗时操作——这些不会被数据库感知，但会让事务悬停
- 使用连接池时，确保
removeAbandonedOnBorrow = true（DBCP）或leak-detection-threshold（HikariCP）开启，并设合理阈值（如 60 秒）
MySQL 服务端能设的硬性防护
不能全指望应用守规矩，服务端要兜底：
- 设置
innodb_lock_wait_timeout = 50（默认 50 秒），让锁等待主动失败，避免雪球式阻塞 - 启用
wait_timeout和interactive_timeout（建议统一设为 300），断开空闲连接，间接终结其持有的事务 - 对高危环境，可临时开启
innodb_rollback_on_timeout = ON，让超时的事务自动回滚（注意：5.7+ 默认 OFF，且只对锁等待超时生效，不覆盖lock_wait_timeout）
真正难处理的是那种“已开始、无 SQL 正在执行、也不响应 KILL”的事务——它往往卡在应用层网络层或死锁检测间隙，这时候只能靠业务侧定位并重启对应服务实例。
