根本原因是应用层未管控事务生命周期，导致连接被长时间占用；应通过代码兜底（defer/try-finally）、避免事务内阻塞操作、客户端设置statement timeout、连接池启用泄漏检测等手段治理。
事务长时间不提交导致连接被占满
MySQL 事务没提交或回滚，连接就一直挂着，wait_timeout 和 interactive_timeout 压根不生效——因为事务内连接始终处于“活跃”状态。这时新请求连不上，报错通常是 Too many connections 或卡在 Waiting for table metadata lock。
根本原因不是连接数设小了，而是应用层没管住事务生命周期。常见场景：代码里开了事务但忘了 commit 或 rollback；异步任务中数据库操作没兜底；或者用了长事务做报表导出，中途网络断了却没触发超时清理。
- 用
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW()) - TIME_TO_SEC(TRX_STARTED) > 60定期查超 60 秒的事务 - 在应用层所有事务入口加
defer（Go）或try/finally（Java/Python），确保无论是否异常都执行rollback或commit - 避免在事务里做 HTTP 调用、文件读写、sleep 等阻塞操作
innodb_lock_wait_timeout 不等于事务超时
innodb_lock_wait_timeout 只控制「等锁」的最长等待时间，比如两个事务同时更新同一行，其中一个会等最多这个值（默认 50 秒），超时后报错 Lock wait timeout exceeded。但它不会杀掉整个事务，也不会释放连接。
真正决定连接何时释放的是 wait_timeout（非交互式连接）和 interactive_timeout（交互式连接），单位秒，默认 28800（8 小时）。但注意：只要事务没结束，这两个参数就不起作用。
- 别指望调低
innodb_lock_wait_timeout来解决连接堆积——它只影响锁冲突，不影响空挂事务 - 如果业务确实需要长事务（如批量数据迁移），应单独用独立连接池 + 显式连接管理，避免污染主业务连接
- 监控项要加上
SHOW ENGINE INNODB STATUS中的TRANSACTIONS部分，重点关注TRX_WAITING和TRX_MYSQL_THREAD_ID
应用层设置 statement timeout 更有效
比起依赖 MySQL 自身超时机制，从客户端控制更精准。JDBC 有 setQueryTimeout()，Python 的 pymysql 支持 connect(timeout=...) 和 cursor.execute(..., timeout=...)，Go 的 database/sql 可通过 context.WithTimeout 控制单次查询。
这类超时能在语句执行卡住时主动中断，触发连接归还到池中，比等 MySQL 自己断连快得多。而且它对事务内多条语句也生效——比如第二条 UPDATE 卡住，timeout 一到就 rollback 并 close 连接。
- JDBC 示例：
PreparedStatement.setQueryTimeout(30)表示单条 SQL 最多跑 30 秒 - Python
pymysql：创建连接时传connect_timeout=10，执行时传timeout=5 - 连接池（如 HikariCP）必须开启
leakDetectionThreshold，否则超时未归还的连接会被静默吃掉
wait_timeout 设太小反而引发重连风暴
把 wait_timeout 从默认 28800 改成 60 秒，看似能更快回收空闲连接，但实际会导致连接池频繁重建连接。尤其在高并发下，大量线程同时发现连接已关闭，争抢新建连接，MySQL 的 Threads_created 指标会飙升，CPU 陡增。
这不是资源节约，是把问题从“连接占满”转移到“连接创建开销过大”。真实瓶颈往往不在连接闲置时长，而在事务没及时收口。
- 建议
wait_timeout保持默认或设为 300–600 秒，重点盯Aborted_connects和Threads_created是否异常增长 - 连接池最大空闲时间（如 HikariCP 的
maxLifetime）应略小于wait_timeout，避免连接被 MySQL 主动 kill 后池子还不知道 - 上线前用
pt-kill --busy-time 60 --kill模拟清理长事务，观察应用是否真能自动恢复
事务边界模糊、缺乏上下文追踪、超时配置分散在不同层级——这些才是导致资源浪费的根本复杂点。光调 MySQL 参数，治标不治本。
