应统一设置wait_timeout和interactive_timeout为300–900秒，并通过SHOW GLOBAL VARIABLES确认生效；已存在Sleep连接需手动KILL清理，同时应用层须配合连接池健康检查与正确关闭逻辑。
MySQL里大量 Sleep 进程不是“看起来没事”，而是正在 silently 消耗连接数、内存和文件描述符——尤其当 max_connections 接近上限时，新连接会直接被拒，报 Too many connections。
为什么 set global wait_timeout 看似没生效？
常见错觉：执行了 SET GLOBAL wait_timeout = 300，再用 SHOW VARIABLES LIKE 'wait_timeout' 查，值还是 28800。这是因为 SHOW VARIABLES 默认查的是**当前会话变量**，不是全局值。
- 查全局配置必须用：
SHOW GLOBAL VARIABLES LIKE 'wait_timeout' - 改完后，**已存在的连接不会立即重载该值**——它们仍沿用建立时继承的会话级
wait_timeout，只有新建连接才生效 - 如果你用的是连接池（如 HikariCP、Druid），还要确认池子本身配置的
idleTimeout≤ MySQL 的wait_timeout，否则池子会提前驱逐连接，反而引发重连风暴
wait_timeout 和 interactive_timeout 到底该设多少？
这两个参数不能只调一个，也不建议设成完全不同的值：
-
wait_timeout控制 JDBC、ORM、应用代码这类**非交互式客户端**的空闲超时（绝大多数生产场景走这个） -
interactive_timeout控制mysql命令行、Navicat 等**交互式工具**的空闲超时 - 官方默认都是 28800 秒（8 小时），对线上服务来说太长；实战中推荐统一设为
900（15 分钟）或300（5 分钟），具体看业务平均请求间隔 - 设太小（比如 60 秒）可能触发
MySQL server has gone away，尤其在慢查询、大事务、网络抖动时
如何立刻清理现有 Sleep 连接？
等超时自动清理太慢，尤其当已有几百个 Sleep 占着连接不放时，得手动干预：
- 先定位：执行
SHOW PROCESSLIST，重点关注Command = 'Sleep'且Time > 300的连接 - 批量杀掉：用 SQL 生成 KILL 语句（别手敲）：
SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE Command = 'Sleep' AND Time > 300;复制结果执行即可 - 注意权限：
KILL需要SUPER或CONNECTION_ADMIN权限；普通账号只能杀自己的连接 - 别用
KILL -9：MySQL 的KILL是优雅中断，不是系统级强制终止
真正根治 Sleep 泛滥，得从应用层配合
调低 wait_timeout 只是兜底，不是替代正确编码习惯：
- PHP 中
mysql_close()必须在所有输出（如echo）之后调用，否则响应未发完连接就关了，后续请求可能复用残留连接 - Java 里确保
Connection.close()在finally块或 try-with-resources 中执行，避免异常跳过释放 - 检查 ORM 是否启用了连接泄漏检测（如 MyBatis 的
leakDetectionThreshold），并打开日志观察连接生命周期 - 连接池配置示例（HikariCP）：
idleTimeout=300000（5 分钟）、maxLifetime=1800000（30 分钟），都应 ≤ MySQL 的wait_timeout
最常被忽略的一点：wait_timeout 调小后，如果应用没做连接有效性校验（如 testOnBorrow 或 validationQuery），首次复用被 MySQL 主动断开的连接时，会直接抛异常——这不是配置错了，而是漏了健康检查。
