必须将wait_timeout和interactive_timeout设为相同值，否则交互式连接仍按默认28800秒保持空闲，易被滥用；生产环境建议统一设为300或600秒，并同步调整连接池maxLifetime小于该值至少30秒。
必须同时设 wait_timeout 和 interactive_timeout，且值一致；只改一个等于没改。
为什么 wait_timeout 和 interactive_timeout 必须设成一样？
MySQL 不会自动同步这两个参数。应用代码用 JDBC 连的是非交互式连接，走 wait_timeout；但 DBA 用 Navicat、mysql 命令行连的是交互式连接，走 interactive_timeout。如果只调小 wait_timeout=300，却漏掉 interactive_timeout，那开发连着不关的客户端仍能空闲 8 小时（默认 28800），持续占着连接槽位。
- 生产环境建议统一设为
300（5 分钟）或600（10 分钟） - 设
300更适合高并发短事务，释放快；设600更兼容轮询类逻辑 - 修改后需重启 MySQL 或执行
SET GLOBAL（注意权限和持久化）
连接池的 maxLifetime 怎么对齐 MySQL 的超时？
MySQL 主动断开连接只是第一步。连接池若继续复用已被服务端 kill 的连接，下一次 executeQuery 就报 MySQL server has gone away。所以池子必须“提前退休”老化连接。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- HikariCP：设
maxLifetime=270000（4.5 分钟），比wait_timeout=300少至少 30 秒 - Druid：对应是
maxEvictableIdleTimeMillis=270000 - 别依赖
testOnBorrow+validationQuery=SELECT 1：每次取连接都查库，QPS 高时直接拖垮 DB - 推荐用
connectionInitSql=SELECT 1（HikariCP）或keepaliveTime做轻量心跳
怎么验证配置真生效了，而不是只写在配置文件里？
别信 my.cnf，也别只看 SHOW VARIABLES。要观察运行时真实行为：
- 执行
SHOW PROCESSLIST;，重点找State = 'Sleep'且Time > 300的行——如果还有，说明参数没生效，或连接正卡在未提交事务里 - 查
SHOW VARIABLES LIKE '%timeout%';，确认wait_timeout和interactive_timeout确实是你要的值（不是 28800） - 注意：旧连接不会立即断开，得等自然超时或重启应用连接池才刷新
最容易被忽略的是：connect_timeout 和 net_read_timeout 完全不负责清理 Sleep 连接，它们管的是握手阶段和查询执行中的卡顿。调错地方，Sleep 该堆还是堆。
