mysql连接超时问题根源在于wait_timeout与连接池生命周期不匹配，需同步配置interactive_timeout并优先调整连接池参数，如hikaricp的maxlifetime应比wait_timeout短5–10分钟。
wait_timeout 默认 28800 秒（8 小时）并不算“过短”，真正的问题是：这个值在连接建立后就固化为会话变量，且应用层无法靠重连自动绕过它。很多报错如 Communications link failure 或 MySQL server has gone away，表面看是“超时”，实则是连接池里还存着一个已被 MySQL 主动断开的旧连接。
查清楚你当前生效的 wait_timeout 和 interactive_timeout 值
不要只信文档或配置文件里写的值——不同启动方式、客户端类型、甚至 JDBC 驱动版本都会影响实际行为。
连上 MySQL 执行：
SHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'interactive_timeout';
注意两点：
-
wait_timeout控制非交互式连接（比如 JDBC 应用），但部分连接池（如 Druid）会显式声明CLIENT_INTERACTIVE，此时实际走的是interactive_timeout - 两个值不一定相等，且会话级变量初始化时只读一次全局值，之后改
SET GLOBAL不会影响已有连接
别只改 my.cnf 里的 wait_timeout，interactive_timeout 必须同步调
MySQL 启动时，会话的 wait_timeout 值取决于客户端类型：非交互式连接取全局 wait_timeout，交互式连接取全局 interactive_timeout。JDBC 默认是非交互式，但某些驱动或连接池封装会悄悄加 CLIENT_INTERACTIVE 标志。
所以必须在 /etc/my.cnf（Linux）或 my.ini（Windows）的 [mysqld] 段落下同时写：
wait_timeout = 388000 interactive_timeout = 388000
切记：
- 不要写在
[client]段落——那只是影响mysql命令行客户端自身行为 - 改完必须
sudo systemctl restart mysql（不是reload），否则配置不加载 - 设太大（比如 31536000 秒≈1年）会导致空闲连接长期占满
max_connections，高并发时直接堵死
HikariCP / Druid 连接池配置比改 MySQL 更安全可控
生产环境优先调连接池，而不是盲目拉长 wait_timeout。原因很实在：
- HikariCP 的
maxLifetime默认是 1800000 毫秒（30 分钟），如果 MySQL 设了 7200 秒（2 小时），连接池会在 MySQL 断开前就主动销毁连接 - HikariCP 推荐用
connection-init-sql=SELECT 1（MySQL 8.0.22+）或connection-test-query=SELECT 1（旧版），配合validation-timeout=3000和test-on-return=true - Druid 要开
testWhileIdle=true，并设timeBetweenEvictionRunsMillis=30000（30 秒巡检一次） - JDBC URL 里加
autoReconnect=true已被 MySQL 官方废弃，5.5+ 版本完全失效，还会掩盖事务断裂风险
最容易被忽略的点：连接池生命周期和 MySQL 超时必须错开
连接池的 maxLifetime（如 HikariCP）、minEvictableIdleTimeMillis（如 Druid）必须比 MySQL 的 wait_timeout 短至少 5–10 分钟。否则会出现“连接池认为还能用，MySQL 却已断开”的窗口期。
例如 MySQL 设了 wait_timeout = 3600（1 小时），HikariCP 就该设 maxLifetime = 3000000（50 分钟），再配上 idleTimeout = 600000（10 分钟）和健康检测，才能稳住首次请求不报错。
这不是参数对齐问题，而是连接状态不可见性导致的必然竞争——MySQL 不通知客户端“我要断你”，客户端只能靠自己定期探测或提前弃用。
