必须同时设置interactive_timeout和wait_timeout，因为新连接的会话wait_timeout初始化时继承自interactive_timeout，只改一个会导致配置失效、重启丢失或云数据库不支持。
Interactive_timeout 参数单独修改基本无效，因为 JDBC 连接默认走 non-interactive 模式，实际受 wait_timeout 控制；但这两个变量在会话初始化时互相影响，只改一个容易被覆盖或不生效。
为什么 SET GLOBAL interactive_timeout 不起作用
Java 应用通过 JDBC 连接 MySQL 时，connection.isWrapperFor(Connection.class) 返回 true，且连接类型被识别为 non-interactive —— 所以服务端查的是 wait_timeout 值，不是 interactive_timeout。但问题在于：wait_timeout 的初始值，会根据全局 interactive_timeout 和客户端类型动态推导。比如你只执行 SET GLOBAL interactive_timeout = 300，wait_timeout 可能仍保持 28800，下次新会话初始化时就按旧值设了。
- 执行
SHOW VARIABLES LIKE '%timeout%'，如果两行数值不一致，说明配置没同步生效 -
SET GLOBAL是临时命令，MySQL 重启即丢失，不能用于生产环境 - 某些云数据库（如阿里云 RDS）不支持
SET GLOBAL，直接报错Access denied; you need SUPER privilege
my.cnf 中必须同时配 wait_timeout 和 interactive_timeout
Linux 下编辑 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf，Windows 下是 %MYSQL_HOME%\my.ini，在 [mysqld] 段下写：
wait_timeout = 28800 interactive_timeout = 28800
注意以下几点：
- 不要只写一个；也不要加注释符号在行首（如
#wait_timeout = 28800），那等于没写 - Linux 最大允许值是
31536000（365 天），Windows 是2147483（约 24.8 天），超限会导致 MySQL 启动失败 - 检查是否有多个
[mysqld]段——只有最后一个段里的同名参数生效；若某段末尾有!include，它引入的文件也参与覆盖 - 改完必须
systemctl restart mysqld（Linux）或通过 Windows 服务管理器重启，reload不生效
HikariCP 必须开启连接有效性检测
就算 MySQL 端 timeout 设成 24 小时，中间经过 NAT、防火墙、负载均衡等设备，连接仍可能被静默断开。HikariCP 默认不验证连接是否存活，得手动配：
- 加配置项
connection-test-query=SELECT 1（MySQL 8.0.19+ 推荐用connection-init-sql=SELECT 1） - 设
validation-timeout=3000（单位毫秒） - 关键：设
max-lifetime略小于wait_timeout，例如 MySQL 设 28800 秒（8 小时），HikariCP 就设max-lifetime=25200（7 小时） - 别忽略
idle-timeout：若设成 600000（10 分钟），而应用每 15 分钟才查一次库，连接池会提前把连接踢掉，再取时就可能遇到Connection reset
phpEnv 或 Docker 环境容易配错路径
phpEnv 自带的 MySQL 是独立安装，不读系统级 /etc/my.cnf；Docker 容器里若用官方镜像，my.cnf 通常在 /etc/mysql/my.cnf 或挂载卷中。常见误操作：
- 改了宿主机的
/etc/my.cnf，但容器内 MySQL 没挂载该文件 - phpEnv 下执行
mysqld --verbose --help | grep "Default options"，发现实际加载的是C:\phpEnv\bin\mysql\my.ini，但你改的是另一个位置 - Docker 启动时加了
--skip-grant-tables或--no-defaults，跳过了所有配置文件 - 验证方式必须是重启后执行
SELECT @@global.wait_timeout, @@global.interactive_timeout;，而不是只信配置文件内容
最麻烦的地方往往不在数据库侧，而在连接池和中间网络设备的协同上——MySQL 说“我等 8 小时”，连接池说“我 30 分钟就换人”，防火墙说“我 5 分钟就砍空闲流”，三者没对齐，调哪个参数都白搭。
