MySQL连接空闲8小时断开的根因是wait_timeout默认28800秒且会话固化，须从服务端配置或连接池层解决；需同时检查并调整wait_timeout与interactive_timeout，优先通过连接池（如HikariCP）的idle-timeout和max-lifetime主动管理连接生命周期。
MySQL 连接空闲 8 小时后自动断开，根本原因是 wait_timeout 默认值为 28800 秒（8 小时），且该值在连接建立后即固化为会话级变量，应用无法靠“重连一次”就绕过——必须从服务端或连接池层面对症处理。
查当前 wait_timeout 和 interactive_timeout 实际值
不要只信文档默认值，不同 MySQL 版本、启动方式、客户端类型（如 JDBC vs mysql 命令行）会导致实际生效值不同。直接连上 MySQL 执行：
SHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'interactive_timeout';
注意：wait_timeout 控制非交互式连接（如 JDBC 应用），interactive_timeout 控制交互式连接（如 mysql 客户端）。JDBC 连接默认走 wait_timeout 路径，但部分驱动或连接池会显式声明 CLIENT_INTERACTIVE，此时会受 interactive_timeout 影响——两个都得查、都得调。
永久修改需改 my.cnf 并重启 mysqld
仅用 SET GLOBAL wait_timeout = 388000 是临时的，MySQL 重启后失效，且新连接是否继承还取决于启动时读取的配置文件。必须编辑配置文件：
- Linux 下通常是
/etc/my.cnf或/etc/mysql/my.cnf，Windows 下是my.ini - 在
[mysqld]段落下添加两行：wait_timeout = 388000 interactive_timeout = 388000
- 不加
[client]段落里的同名配置 —— 那里只影响 mysql 命令行等客户端行为，不影响服务端判定空闲超时 - 保存后执行
sudo systemctl restart mysql（或mysqld），不是 reload，必须完整重启进程
JDBC URL 加 autoReconnect=true 已失效
MySQL 5.5+ 版本中，autoReconnect=true 不再触发自动重连逻辑，只会让驱动在报错后抛出异常，不会静默重建连接。实测开启后仍会抛出 CommunicationsException: Communications link failure。更危险的是，它可能掩盖事务一致性问题——比如前一条语句已提交，重连后下一条执行在新会话里，造成逻辑断裂。官方文档明确标注该参数已废弃，不应依赖。
连接池配置比改数据库更可控
生产环境推荐优先调整连接池（如 HikariCP、Druid），而非盲目拉长 wait_timeout。原因很实在：
- 数据库侧设太大（如设成 388000 秒 ≈ 4.5 天），等于放任大量空闲连接长期占用
max_connections名额，高并发时易触顶 - HikariCP 的
connection-timeout控制获取连接的等待时间，idle-timeout控制连接在池中最大空闲时长（默认 10 分钟），max-lifetime控制连接最大存活时间（默认 30 分钟）——这三个参数共同作用，能主动驱逐将要过期的连接，避免撞上 MySQL 的wait_timeout - 配合
connection-test-query=SELECT 1或 HikariCP 内置的connection-test-query（如isValid()），可在借出前检测连接有效性，比等运行时爆错更早干预
真正容易被忽略的点是：很多团队把连接池的 max-lifetime 设成 0（无限）或远大于 wait_timeout，结果连接池以为连接还健在，MySQL 却已在后台悄悄 kill 掉——这种“错位”才是故障高发根源。
