innodb_rollback_on_timeout=on对僵尸事务完全无效，因其仅响应锁等待超时（error 1205）事件，而僵尸事务处于running且trx_query=null状态，不争锁、不触发等待，故无法激活该参数；需通过查询innodb_trx中trx_started超时记录主动识别并kill线程清理。
开启 innodb_rollback_on_timeout = ON 不能探测僵尸事务，它只在锁等待超时（ERROR 1205）发生时决定是否回滚整个事务——而僵尸事务本身不触发该错误，它只是“静默悬挂”，连锁等待都不一定有。
为什么 innodb_rollback_on_timeout 对僵尸事务完全无效
僵尸事务（zombie transaction）指已执行 BEGIN 或隐式开启、但长期未 COMMIT 或 ROLLBACK 的事务。它可能持锁、占内存、阻塞 MVCC 清理，但只要不尝试获取新锁、不读写冲突行，就不会触发 Lock wait timeout exceeded，也就根本不会走到 innodb_rollback_on_timeout 的判断逻辑。
-
innodb_rollback_on_timeout是静态参数，仅响应ERROR 1205这一类明确的锁等待超时事件 - 僵尸事务通常处于
TRX_STATE = RUNNING状态，且TRX_QUERY = NULL（没在执行语句），所以不满足触发条件 - 即使你手动等满
innodb_lock_wait_timeout，也得先有“等待”行为；僵尸事务若不主动争锁，就永远等不到
真正能发现僵尸事务的手段：查 information_schema.innodb_trx
必须主动轮询运行中的事务元数据，重点关注持续时间异常的 TRX_STARTED 时间戳。以下查询可快速定位活跃超 30 分钟的事务：
SELECT trx_id, trx_started, TIMESTAMPDIFF(MINUTE, trx_started, NOW()) AS duration_min, trx_state, trx_query, trx_mysql_thread_id AS thread_id FROM information_schema.innodb_trx WHERE TIMESTAMPDIFF(MINUTE, trx_started, NOW()) > 30 ORDER BY duration_min DESC;
- 结果中
trx_query IS NULL且duration_min > 30是典型僵尸信号 -
trx_state = RUNNING说明事务仍打开，未被客户端断开或自动清理 - 搭配
information_schema.processlist可查出对应连接的USER、HOST、COMMAND和空闲时间TIME
如何安全终止疑似僵尸事务
确认后需人工干预 kill，但不能直接杀线程了事——要先评估影响。推荐分两步操作：
- 先用
KILL QUERY thread_id尝试中断当前语句（如果trx_query非空），避免误杀正在执行关键逻辑的会话 - 若仍无响应或
trx_query为空，再用KILL thread_id终止连接；MySQL 会在连接断开时自动回滚其未提交事务 - 生产环境建议加条件过滤：只 kill
COMMAND = 'Sleep'且TIME > 1800（30 分钟空闲）的连接，降低误伤风险
预防比探测更重要：从源头堵住僵尸事务
靠事后扫描是兜底，不是常态方案。以下三点落地后，95% 的僵尸事务可避免：
- 应用层所有事务必须带超时控制：Spring 的
@Transactional(timeout = 30)要配合DataSourceTransactionManager正确生效（注意它依赖ConnectionHolder的 deadline，不是 MySQL 层面的 timeout） - 禁用长连接上的隐式事务：确保
autocommit = 1，所有显式事务都用BEGIN ... COMMIT/ROLLBACK明确包裹，杜绝“开了不关” - 数据库侧配置连接空闲回收：
wait_timeout和interactive_timeout设为 600–1800 秒，让空闲连接自动断开，触发事务回滚
真正危险的从来不是锁等待超时，而是那些没人记得自己还开着的事务——它们不报错、不阻塞、不释放资源，直到某天突然拖垮整个实例。
