应立即检查未提交事务并修复应用代码逻辑，因Sleep连接超时是事务未提交/回滚所致，MySQL不会主动回收活跃事务中的Sleep连接，需结合information_schema.processlist与innodb_trx定位并终止异常事务。
SHOW PROCESSLIST 里大量 Sleep 状态且 Time 超过 wait_timeout 怎么办
这不是连接没被释放，而是事务没提交/回滚，导致连接卡在 Sleep 状态却仍持有事务锁和连接资源。MySQL 不会主动回收处于活跃事务中的 Sleep 连接——哪怕它已经空闲了 10 分钟，只要 autocommit=0 且没执行 COMMIT 或 ROLLBACK，这个连接就一直算“被占用”。
- 先运行
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.processlist WHERE COMMAND = 'Sleep' AND TIME > 60 ORDER BY TIME DESC LIMIT 10，重点关注INFO列是否为空（说明没在跑 SQL，但事务未结束） - 结合
SELECT * FROM information_schema.innodb_trx ORDER BY trx_started LIMIT 5，确认这些 Sleep 连接是否对应着长时间未提交的事务（trx_state = 'RUNNING'且trx_started时间很早） - 检查应用日志中是否有 “transaction timeout”、“could not commit”、“rollback failed” 等异常记录，尤其是嵌套事务场景下外层 try-catch 吞掉内层异常，导致外层事务无法正常结束
Python 中用 with conn.cursor() 但事务仍不释放连接？
PyMySQL/MySQLdb 的 with 语句只保证 cursor 关闭，不控制 connection 生命周期，更不自动提交事务。如果代码里显式调用了 conn.begin() 或设置了 autocommit=False，又没配 try/finally 或上下文管理器包裹 conn 本身，就会出现“光标关了，连接还挂着，事务还开着”的三重泄漏。
- 错误写法：
with conn.cursor() as cur: cur.execute("UPDATE ..."); conn.begin()——begin()在with外，事务状态脱离管理 - 正确做法：要么全程用
autocommit=True（适合简单 CRUD），要么用with conn: ...（PyMySQL 1.0+ 支持，自动 commit/rollback），或手动确保每个conn.begin()都有匹配的conn.commit()/conn.rollback() - 特别注意 ORM 场景：SQLAlchemy 的
session.begin_nested()如果没配savepoint回滚逻辑，外层异常时嵌套事务可能残留，表现为连接池里一堆 Sleep 连接 +innodb_trx中多个未结束事务
Java Spring @Transactional 嵌套时 connection 不释放的典型原因
Spring 默认的 PROPAGATION_REQUIRED 是“复用当前事务”，不是新开连接；但一旦发生异常且没有被正确捕获，外层事务可能卡在 rollback 阶段，而连接池（如 HikariCP）会认为该连接仍在使用中，拒绝归还。
- 常见陷阱：在
@Transactional方法里调用另一个@Transactional(propagation = Propagation.REQUIRES_NEW)方法，后者抛出异常但被外层吞掉，导致外层事务无法判断是否该回滚 - 验证方式：查
HikariPool-1 - Timeout failure stats日志，若频繁出现Connection has been closed或Connection marked as broken，大概率是事务异常中断后连接未清理干净 - 临时缓解：设置
spring.datasource.hikari.leak-detection-threshold=60000（单位毫秒），让连接池主动标记并关闭泄漏连接；但根因必须改代码——所有REQUIRES_NEW必须配try/catch显式处理异常，避免污染外层事务状态
为什么 kill 掉 Sleep 连接后，新连接立刻又变成 Sleep？
这不是连接池配置问题，是业务逻辑里存在“静默失败”的事务路径。比如一个下单接口，内部开启事务后调用支付 SDK，SDK 返回超时，但代码只打印 warn 日志、没抛异常、也没执行 rollback，整个方法平静返回，连接就带着未提交事务回到池里，下次被借走时仍是脏状态。
- 关键检查点：翻应用日志关键词
timeout、interrupted、failed to，配合时间戳比对processlist中 Sleep 连接的TIME字段起始时间 - 数据库侧辅助定位：开启
innodb_status_output_locks=ON，再查SHOW ENGINE INNODB STATUS\G的TRANSACTIONS部分，看是否有大量lock struct(s)持有但无对应 SQL 执行 - 最硬核手段：在连接池层加钩子，如 HikariCP 的
connection-init-sql=SELECT 1+ 自定义ProxyConnection，记录每次getConnection()和close()的堆栈，精准定位哪段代码拿了连接不还
事务嵌套带来的连接泄漏，往往藏在“看起来执行完了”的代码路径里。真正难排查的不是长事务，而是那些连 ERROR 日志都不打、只留下 Sleep 连接和悬停事务的静默失败。
