会，autocommit=0时连接不释放的底层机制是：事务未显式提交或回滚前，连接始终处于活跃事务状态，wait_timeout失效，服务端无法主动断开；常见陷阱包括ORM未全覆盖commit/rollback、@Transactional未配置rollbackFor、连接池默认关闭autocommit但无事务管理器等。
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 —— 这类连接大概率卡在未结束的事务里。
更准的方法是加条件过滤：
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 当成“性能优化”手段——它不减少锁持有时间，反而放大连接泄漏风险，尤其在微服务多跳调用场景下，一个未关闭的事务可能拖垮整条链路的连接资源。
