为什么MySQL自动提交关闭后连接数暴涨？-mysql教程-PHP中文网

会，autocommit=0时连接不释放的底层机制是：事务未显式提交或回滚前，连接始终处于活跃事务状态，wait_timeout失效，服务端无法主动断开；常见陷阱包括orm未全覆盖commit/rollback、@transactional未配置rollbackfor、连接池默认关闭autocommit但无事务管理器等。

为什么mysql自动提交关闭后连接数暴涨？

autocommit=0 时连接不释放的底层机制

MySQL 默认 autocommit=1，每个 SQL 执行完立刻提交，事务生命周期极短，连接很快退回 Sleep 状态并受 wait_timeout 控制。一旦设为 autocommit=0，事务就不再自动结束——哪怕只执行一条 SELECT，只要没显式 COMMIT 或 ROLLBACK，连接就始终处于活跃事务状态，wait_timeout 不生效，连接不会被服务端主动断开。

哪些代码路径会意外卡住事务

常见但容易被忽略的陷阱：

ORM 框架（如 MyBatis、Hibernate）在手动开启事务后，未在所有分支（尤其是 catch 和 finally）调用 commit() 或 rollback()
Spring 的 @Transactional 注解方法中抛出非 RuntimeException，而事务传播行为是 REQUIRED 且未配置 rollbackFor，导致事务未回滚但连接未释放
连接池配置了 defaultAutoCommit=false，但业务代码没配事务管理器，也未手动控制提交
应用层做“读写分离”路由时，误将只读查询发到主库且开启了事务，后续又没关闭

怎么快速定位 autocommit=0 引发的连接堆积

直接查 information_schema.processlist 中那些长时间 Command=Sleep 但 State=Waiting for table metadata lock 或 State=executing 的连接，再结合 Info 列看是否为空或只有 SELECT —— 这类连接大概率卡在未结束的事务里。

更准的方法是加条件过滤：

MySQL

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

下载

SELECT id, user, host, db, command, time, state, info
FROM information_schema.processlist
WHERE command = 'Sleep' AND time > 60
  AND (SELECT @@autocommit FROM DUAL) = 0;

如果结果集中大量连接的 time 持续增长，且对应应用日志里没有 COMMIT 或 ROLLBACK 记录，基本可锁定问题。

修复必须从两端同时下手

单改 MySQL 配置治标不治本。必须同步处理：

应用侧：确认所有数据库访问路径都明确控制事务边界，禁用全局 autocommit=0，改用显式事务块或框架级事务管理
连接池侧：HikariCP 设置 connection-init-sql=SET autocommit=1；Druid 设置 initConnectionSqls=SET autocommit=1
MySQL 侧：避免在 my.cnf 中写 autocommit=0；若必须关，需配套监控 innodb_trx 表中 trx_started 时间过长的事务

最危险的是把 autocommit=0 当成“性能优化”手段——它不减少锁持有时间，反而放大连接泄漏风险，尤其在微服务多跳调用场景下，一个未关闭的事务可能拖垮整条链路的连接资源。