长事务未提交导致连接池耗尽，应先查innodb_trx中运行超60秒的事务，再结合锁等待、活跃连接及hikari日志定位“占着不还”源头，最后通过事务拆分、逻辑外移、超时控制与连接池防护双路治理。
长事务没提交，连接就一直被绑在线程上不放，池子里的连接越借越少，新请求卡在排队队列里，直到报 Connection is not available, request timed out——这不是数据库扛不住，是连接被悄悄锁死、没人还。
快速定位谁在“占着不还”
别急着调大连接数，先查数据库里真正在拖时间的事务：
- MySQL 执行：
SELECT trx_id, trx_started, TIMEDIFF(NOW(), trx_started) AS duration, trx_state, trx_query FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(TIMEDIFF(NOW(), trx_started)) > 60;
重点关注trx_state = 'RUNNING'且duration持续上涨的记录 - 顺手看看有没有锁住别人：
SELECT * FROM sys.innodb_lock_waits; - 再核对应用侧当前活跃连接：
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep';
盯紧 @Transactional 里的“脏活”
声明式事务本身没问题，但一旦方法里干了耗时操作，连接就会全程陪跑：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 同步调用外部服务（如 Feign、RestTemplate），对方响应慢或超时
- 在事务里读写大文件、解析超大 Excel/JSON、做密集计算
- 误把校验、通知、日志等非 DB 操作塞进事务方法
- 写了
Thread.sleep()或等待条件变量这类显式挂起
验证方法：开启 Hikari DEBUG 日志，比对 Connection opened 和 Connection returned to pool 的时间差——如果基本等于整个方法执行时长，问题就坐实了。
从代码和配置双路堵漏
光靠排查不够，得让系统有防御力：
- 事务拆分：批量操作改成分批提交，比如每 100 条 commit 一次，别一个事务插百万条
- 逻辑外移：把远程调用、文件处理等非原子操作移到
@Transactional方法之外 - 强制设超时：
@Transactional(timeout = 10)或在配置中全局设spring.transaction.default-timeout=10 - 连接池加防护：
Hikari 配leak-detection-threshold=30000（30秒），泄漏时打堆栈；
设maxLifetime=1800000（30分钟）防连接老化，connectionTimeout=30000控制获取上限
监控要看到真实水位
不能只看最大连接数配了多少，得盯运行时指标：
- 活跃连接数持续 ≥ 最大值的 90%
- 等待获取连接的线程数 > 0 且持续增长
- 连接平均持有时间突然拉长（比如从 200ms 跳到 5s+）
- 配合 APM 工具（如 SkyWalking）追踪事务链路，直接定位哪一行代码拖住了连接
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
