必须查清当前生效的 wait_timeout 和 interactive_timeout 值，二者可能不一致；永久修改需在 my.cnf 的 [mysqld] 段统一配置并重启 mysql；连接池需设 max-lifetime 小于 wait_timeout 至少 30 秒，并启用探活与空闲检测。
查清楚当前生效的 wait_timeout 和 interactive_timeout 值
别猜默认值，不同环境差异极大：本地 MySQL 可能是 28800 秒（8 小时），阿里云 RDS 常设为 300 秒（5 分钟），AWS RDS 最小强制为 60 秒。JDBC、PyMySQL 等非交互式连接走 wait_timeout，但部分连接池会带 CLIENT_INTERACTIVE 标志，实际受 interactive_timeout 控制——两个都得查。
连上数据库后直接执行：SELECT @@wait_timeout, @@interactive_timeout;
注意单位是秒；如果返回值不一致，说明服务端行为已分裂，后续排查会绕弯子。
永久修改必须改 my.cnf 并重启 mysqld
SET GLOBAL wait_timeout = 600 是临时的，MySQL 重启就回滚，且新连接是否继承还取决于配置文件读取顺序。生产环境必须编辑配置文件：
- Linux/macOS 下找
/etc/my.cnf或/etc/mysql/my.cnf - phpEnv 用户看
/usr/local/phpenv/config/mysql/my.cnf - Windows 下是
my.ini
只在 [mysqld] 段落下加两行（务必一致）：wait_timeout = 600interactive_timeout = 600
删掉 [client] 段里的同名配置——那只是给 mysql 命令行用的，不影响服务端判定。
改完必须执行：sudo systemctl restart mysql
不是 reload，否则零生效。
HikariCP / Druid 连接池必须比 MySQL 更早“动手”
把 wait_timeout 设成 600 秒（10 分钟），但 HikariCP 的 max-lifetime 默认是 1800000 毫秒（30 分钟），连接池根本等不到 MySQL 断它，自己先销毁了；反过来，如果 max-lifetime 设成 3600000 毫秒（1 小时），而 idle-timeout 是 600000 毫秒（10 分钟），那连接大概率在被 MySQL 杀之前就被池子回收了。
真正要稳，得满足三个条件：
-
max-lifetime必须比wait_timeout小至少 30 秒（例如 MySQL 设 600，池子设 570000 毫秒） - 开启探活：
connection-test-query=SELECT 1（MySQL 8.0+ 可用isValid()） - 启用空闲检测：
test-while-idle=true（别用test-on-borrow=true，每次取连接都查，延迟高）
绝对不要配 autoReconnect=true——MySQL 5.5+ 已废弃，它不重连，只抛 CommunicationsException，还可能破坏事务一致性。
已存在的 Sleep 连接不会自动清理
SET GLOBAL 或改配置文件，只影响新建连接；已存在的 Sleep 连接仍沿用旧的会话级 wait_timeout，继续占着 max_connections、内存和文件描述符。如果 SHOW PROCESSLIST 里大量 Sleep 进程，需手动清理：
查出超时连接：SELECT ID, USER, HOST, TIME, STATE FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 300;
再逐个 KILL：KILL 123;（123 是查到的 ID）
更稳妥的做法是在连接池初始化 SQL 中加一句：connection-init-sql=SET SESSION wait_timeout = 600
这样每个新连接一建好就固化自己的超时值，避免受全局配置滞后影响。
