关闭autocommit后未显式COMMIT或ROLLBACK是MySQL 5.7长事务最常见成因；它使事务静默存活，持续持锁、膨胀undo、阻塞purge，且无报错。
直接结论：关闭 autocommit 后未显式 COMMIT 或 ROLLBACK，是 MySQL 5.7 中长事务最常见、最隐蔽的成因。它不会报错，但会让事务“静默存活”，持续持有锁、膨胀 undo、阻塞 purge 线程。
为什么 SET autocommit = 0 容易埋雷
这不是语法错误，而是语义陷阱：SET autocommit = 0 不启动新事务，也不结束当前事务（如果已有）；它只是让后续所有 DML 都“自动归入当前事务”——而这个“当前事务”可能早已存在、甚至已空闲数分钟。
常见误用场景：
- DBA 或开发在客户端手动执行
SET autocommit = 0调试 SQL，改完几行就切走，忘了COMMIT或ROLLBACK - 应用连接池复用连接后，上一个请求因异常没清理事务状态，下一个请求一上来就继续往里塞 SQL
- 某些 ORM（如旧版 MyBatis）配置了
autoCommit=false，但业务方法没加@Transactional或没走 AOP，导致事务永远不提交
后果比显式 START TRANSACTION 更难察觉：因为没有明确的事务起点，information_schema.innodb_trx 里 trx_started 时间戳可能早于你预期，且 trx_state 常为 RUNNING（即使它什么也没干）。
怎么快速定位这类“幽灵事务”
核心思路：找那些 autocommit=0 且长时间无动作的连接，再关联到其持有的事务。
执行以下查询（适用于 MySQL 5.7）：
SELECT t.trx_id, t.trx_started, t.trx_state, t.trx_rows_modified, p.ID AS conn_id, p.USER, p.HOST, p.DB, p.COMMAND, p.TIME AS conn_idle_time, p.INFO FROM information_schema.INNODB_TRX t JOIN information_schema.PROCESSLIST p ON t.trx_mysql_thread_id = p.ID WHERE p.COMMAND = 'Sleep' AND p.TIME > 30 AND (SELECT @@autocommit) = 0;
关键判断点：
-
COMMAND = 'Sleep'且conn_idle_time > 30：连接空闲超 30 秒，但事务仍开着 -
trx_rows_modified = 0或极小：大概率是调试残留或连接复用污染，不是正在跑的大事务 -
INFO字段为空或只含NULL：说明最后执行的不是 SELECT，很可能是 DML 后没提交
KILL 前必须确认的三件事
别急着 KILL，先验证它是否真安全回滚：
- 查
SHOW ENGINE INNODB STATUS\G的TRANSACTIONSsection，确认该事务没在做purging或rolling back—— 如果已在回滚中，KILL只会让它重来一遍 - 检查
trx_operation_state（需 5.7.16+）是否为fetching rows或updating；如果是sleeping before entering InnoDB，基本可杀 - 确认该连接不属于关键定时任务或监控采集脚本（看
USER和HOST），避免误杀造成业务中断
安全终止命令：
KILL CONNECTION <conn_id>;</conn_id>
注意用 CONNECTION 而非 QUERY，确保整个会话被清理，事务强制回滚。
真正防住的关键不在客户端，而在服务端配置
依赖人肉巡检不可靠。MySQL 5.7 必须协同收紧两个超时参数：
-
innodb_lock_wait_timeout = 10：缩短等锁失败时间，避免事务卡在锁队列里“假死” -
wait_timeout = 600（即 10 分钟）：让空闲连接自动断开，连带终结其未提交事务 —— 这比任何应用层心跳都可靠
这两项修改后，即使代码漏写 COMMIT，最多 10 分钟也会被系统回收。但要注意：应用层必须捕获 Lock wait timeout exceeded 并重试，否则业务逻辑会出错。
最后提醒一句：所有监控脚本、备份工具、DBA 终端连接，只要执行过 SET autocommit = 0，退出前务必补一句 SET autocommit = 1 或 COMMIT。这个习惯比任何自动化都管用。
