MySQL 连接池故障经常表现成一串看似无关的异常：Can't call commit when autocommit=true、连接池耗尽、CommunicationsException、锁等待超时。真正处理时，不要只盯第一条堆栈，而要把连接、事务、网络和锁放在同一条链路里看。
autocommit=true 为什么会报错
Can't call commit when autocommit=true 的意思是：当前连接没有处在显式事务里，却执行了 commit()。在 JDBC 语义里，如果 autocommit=true，每条 SQL 会自动提交，手动 commit 就没有意义。
常见原因有：
- 事务管理器拿到的连接和业务执行 SQL 的连接不是同一个。
- 中途连接异常重连，事务上下文丢失。
- 多数据源或分库分表场景里，某个分片连接状态异常。
- 代码手动改了
setAutoCommit(true)，破坏了框架事务边界。
排查时先看事务入口、数据源路由、连接获取和释放是否一致，不要只在业务方法里加 try-catch。
连接池耗尽不一定是并发太高
连接池耗尽常见提示类似：
Pool empty. Unable to fetch a connection它可能是访问量高，也可能是连接没有归还，还可能是数据库锁等待导致连接长时间占用。
排查顺序可以是：
- 看连接池监控：active、idle、wait count、borrow time。
- 看数据库线程：
show processlist是否大量处在 lock wait、sending data、sleep。 - 看慢 SQL 和锁等待：是否某条 SQL 把事务拖长。
- 看代码：事务里是否调用 RPC、MQ、HTTP 或大文件处理。
如果连接都在等数据库锁，单纯把连接池从 40 调到 200 只是延后崩溃，还可能把数据库打得更重。
CommunicationsException 要结合事务看
CommunicationsException 表示客户端和 MySQL 通信断了。它可能来自网络抖动、数据库重启、连接空闲超时、防火墙中断，也可能是连接池拿到了已经失效的连接。
工程上要确认：
- 连接池是否开启连接有效性检测。
- MySQL
wait_timeout和连接池空闲回收时间是否匹配。 - 网络切换或数据库主从切换时，业务是否有重试和熔断。
- 重试是否会重复提交非幂等操作。
连接断开并不只是“再连一次”这么简单。若断开发生在事务提交边界，要确认数据是否已经提交，避免重复扣款、重复发消息这类问题。
锁等待会把连接池拖死
锁等待超时通常不是孤立问题。一个事务持有锁不释放，其他请求继续进入，连接会越来越多地卡在等待锁上，最后表现为连接池耗尽。
排查锁等待可以看：
show processlist;
show engine innodb status;也可以结合 performance_schema 或监控平台看阻塞链。重点不是只杀掉等待线程，而是找到持锁时间最长的事务：它执行了什么 SQL、有没有合适索引、事务里有没有慢操作。
排障时按链路复盘
一次连接池事故可以按这个顺序复盘：
- 故障入口：最早出现的是网络异常、慢 SQL、锁等待还是连接池耗尽。
- 事务状态：哪些连接处在事务中，是否有提交/回滚失败。
- 数据库状态：是否有锁、慢查询、主从切换或资源瓶颈。
- 连接池状态：最大连接、等待数、活跃连接时长。
- 业务补偿：是否有重复执行、部分成功、消息未发送。
这样能避免把一个数据库锁问题误写成“连接池配置太小”。
最后抓住一句话
MySQL 连接池异常通常是结果，不是根因。autocommit、通信中断、锁等待和连接耗尽要放到同一条事务链路里看：连接从哪里来、事务在哪里开始、锁在哪里等待、连接什么时候归还。
