wait_timeout是mysql服务端控制空闲非交互式连接自动断开的秒数，不直接管理连接池，但若连接池idletimeout≥wait_timeout，复用时必报“mysql server has gone away”；正确做法是让idletimeout严格小于wait_timeout并预留30秒缓冲，同时启用testwhileidle探活。
wait_timeout 是什么，它真管连接池吗？
wait_timeout 是 MySQL 服务端参数，控制**空闲连接在服务器端自动断开前的等待秒数**。它不直接作用于应用层的连接池（如 HikariCP、Druid），但会和连接池协同出问题：当连接池维持的连接空闲时间超过 wait_timeout，MySQL 主动断开后，连接池若未及时检测，下次复用就会抛 MySQLNonTransientConnectionException: Connection.close() has already been called 或类似 Communications link failure 错误。
所以配置目标不是“让 wait_timeout 匹配连接池”，而是**避免服务端单方面断连导致连接失效**。常见误操作是把 wait_timeout 设得极大（比如 24 小时），反而掩盖了连接泄漏或健康检查缺失的问题。
如何安全设置 wait_timeout 和连接池 idleTimeout
关键原则：连接池的空闲连接回收周期必须 严格小于 MySQL 的 wait_timeout，并预留缓冲（建议至少 30 秒）。
- 查当前 MySQL 的
wait_timeout值：SHOW VARIABLES LIKE 'wait_timeout';
默认通常是 28800（8 小时），生产环境常被调低到 300–1800（5–30 分钟） - 以 HikariCP 为例，设
idleTimeout必须比wait_timeout小至少 30 秒：spring.datasource.hikari.idle-timeout=1770000 # 29.5 分钟 → 对应 wait_timeout=1800（30 分钟）
- Druid 则对应
minEvictableIdleTimeMillis，同样需满足：minEvictableIdleTimeMillis - 务必关闭连接池的“testOnBorrow”（性能差），改用
testWhileIdle=true+ 合理的timeBetweenEvictionRunsMillis（如 30 秒）主动探活
监控 wait_timeout 生效是否异常
仅看 SHOW VARIABLES 不够——该值分 global/session 级别，且新连接继承 global，但客户端可自行 SET 覆盖。容易踩的坑：
- 某些 ORM（如早期 MyBatis）或连接池初始化时执行
SET SESSION wait_timeout = ...，会覆盖全局配置，需查SHOW PROCESSLIST中各连接的Time列是否持续增长却不超限 - 监控真实断连：开启 MySQL 慢日志 + general_log（临时），过滤
"Aborted connection"日志；或监听 performance_schema.events_statements_summary_by_digest 表中含"ERROR 2013"的记录 - Prometheus + mysqld_exporter 可抓取
mysql_global_status_aborted_clients，突增说明大量连接被服务端强制中断
为什么 ALTER USER … REQUIRE SSL 会影响 wait_timeout 行为？
这是一个冷门但致命的干扰项：当用户启用了 REQUIRE SSL，MySQL 在 SSL 握手失败时可能跳过常规连接清理流程，导致 wait_timeout 判定失准，SHOW PROCESSLIST 中出现大量 Sleep 状态但 Time 值远超设定值的“僵尸连接”。
验证方式：
SELECT user, host, ssl_type FROM mysql.user WHERE user = 'your_app_user';若返回
ssl_type != 'NONE'，且应用实际未走 SSL，则需：ALTER USER 'your_app_user'@'%' REQUIRE NONE;并重启连接池。
真正难处理的，从来不是参数数字本身，而是连接状态在服务端、网络、连接池三层之间不同步时留下的静默腐烂——一次没校验的 isValid() 调用，就足以让一个本该 30 秒回收的连接，在 wait_timeout 到期后继续挂着 7 小时。
