MySQL连接闲置8小时断开是wait_timeout默认28800秒所致，须同步调整服务端配置（my.cnf中[mysqld]段的wait_timeout与interactive_timeout并重启）和连接池参数（如HikariCP的max-lifetime略小于wait_timeout、启用validation），禁用已废弃的autoReconnect=true，并关注net_read_timeout等配套超时参数。
MySQL连接闲置8小时后断开，不是bug，是wait_timeout默认28800秒在起作用；但光改它不解决实际问题，必须和服务端配置、连接池参数对齐。
查清楚当前生效的wait_timeout和interactive_timeout值
不同环境（云数据库、Docker、自建）默认值可能差异很大，阿里云RDS可能设成300秒，腾讯云CDB可能设成600秒，不能只信文档。连上MySQL后直接执行：
SELECT @@wait_timeout, @@interactive_timeout;
注意两点：
- 返回单位是秒，不是毫秒
- JDBC应用默认走
wait_timeout路径，但如果驱动或ORM显式声明CLIENT_INTERACTIVE（比如某些PyMySQL版本或旧版Hibernate），就会受interactive_timeout控制——所以两个都得查、都得调
永久修改必须写进my.cnf的[mysqld]段并重启
SET GLOBAL wait_timeout = 600这类命令只是临时生效，MySQL重启就回退。生产环境必须编辑配置文件：
- Linux下通常是
/etc/my.cnf或/etc/mysql/my.cnf - Windows下是
my.ini - 在
[mysqld]段落下添加两行（不要加在[client]里）：
wait_timeout = 600<br>interactive_timeout = 600
改完必须执行sudo systemctl restart mysql（不是reload），否则配置不加载。云数据库如AWS RDS不支持直接改配置文件，得走控制台参数组或提工单。
HikariCP或Druid连接池必须同步设maxLifetime和验证机制
只调MySQL的wait_timeout等于半途而废。连接池如果还拿着一个已被MySQL杀掉的连接，下次getConnection()时照样报CommunicationsException: Communications link failure。
- 把连接池的
maxLifetime设为比wait_timeout小10～20秒（例如MySQL设600，池子设580000毫秒） - HikariCP推荐配
connection-test-query=SELECT 1（MySQL 8.0.22+用connection-init-sql）和test-on-borrow=true，或更轻量的test-while-idle=true+validation-timeout=3000 - Druid需开启
testWhileIdle=true，并设timeBetweenEvictionRunsMillis=30000 - 禁用
autoReconnect=true：MySQL 5.5+已废弃，不仅无效，还会掩盖事务断裂风险
别忽略net_read_timeout和connect_timeout这些配套参数
wait_timeout只管“完全没发请求”的空闲期，不防慢查询或网络卡顿。真正导致MySQL server has gone away的，常是下面这些：
-
net_read_timeout：服务端等客户端发下一条SQL太久（比如大结果集传输中断），默认30秒，可设为60 -
net_write_timeout：服务端往客户端写数据超时（如导出大表），默认30秒，可设为120 -
connect_timeout：TCP握手+认证阶段超时，默认10秒，网络不稳定时可适当提高 - 这些参数同样要写进
[mysqld]段，同样需要重启才永久生效
最易被忽略的是：MySQL服务端断连后，错误信息不是timeout字眼，而是Lost connection to MySQL server during query或MySQL server has gone away——这意味着你得从连接池日志和SHOW PROCESSLIST里看Sleep状态持续时间，才能确认是不是wait_timeout真正在起作用。
