如何解决MySQL连接超时wait_timeout设置不当导致的掉线？

MySQL连接掉线主因是wait_timeout与interactive_timeout未配对且未对齐连接池生命周期；必须查会话级实际值SELECT @@wait_timeout, @@interactive_timeout，云环境需通过控制台修改参数模板并重启，5.7与8.0在事务空闲计时逻辑上存在关键差异。

MySQL 连接掉线不是网络抖动，而是服务端主动 kill 了空闲连接——wait_timeout 和 interactive_timeout 没配对、没对齐连接池生命周期，就必然掉。

查清当前生效的 timeout 值到底是多少

别信配置文件里写的，也别只看 SHOW VARIABLES LIKE 'wait_timeout'；MySQL 实际用哪个值，取决于客户端连接时声明的类型（交互式 or 非交互式），而很多 ORM 或连接池会在建连后立刻执行 SET SESSION interactive_timeout = N，导致全局值被覆盖。

必须一次性查全：

1. SELECT @@wait_timeout, @@interactive_timeout; —— 看当前会话实际值
2. SHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'interactive_timeout'; —— 看全局默认值
3. 如果两个结果不一致，说明客户端或驱动改过会话级变量，wait_timeout 很可能已被“悄悄覆盖”

HikariCP 必须显式配有效性检测，否则永远不知道连接已死

Spring Boot 2.3+ 默认关闭连接有效性验证，spring.datasource.hikari.connection-test-query 不再自动 fallback 到 SELECT 1，不配就等于裸奔。

1. 开发/测试环境：开 test-on-borrow=true + connection-test-query=SELECT 1
2. 生产环境：禁用 test-on-borrow（性能损耗大），改用 test-while-idle=true + validation-timeout=3 + idle-timeout=600000
3. maxLifetime 必须比 MySQL 的 wait_timeout 小至少 60 秒，例如 MySQL 设为 600，HikariCP 就设 max-lifetime=540000

云数据库改 timeout 要走控制台，且不能只改一个参数

阿里云 RDS、腾讯云 CDB、AWS RDS 都不让你碰 my.cnf，SET GLOBAL 也基本无效（权限受限或重启即丢）。

1. 必须进控制台 → 找「参数模板」→ 修改 wait_timeout 和 interactive_timeout 两个值 → 绑定到实例并重启（部分云厂商支持热加载，但需确认）
2. 云平台常有取值范围限制（如最小 10 秒、最大 31536000 秒），设成 0 是无效的
3. 别只调大 wait_timeout 却忽略 interactive_timeout：哪怕你用的是 Java 应用，某些 JDBC 驱动（如旧版 mysql-connector-java）仍会按交互式逻辑协商，两个值不等就容易错杀

MySQL 5.7 和 8.0 对事务中空闲计时的行为完全不同

这个差异极隐蔽，但直接决定“卡在 BEGIN 后的连接会不会被干掉”。

1. MySQL 5.7：wait_timeout 计时器在事务中暂停，BEGIN 后不执行语句也不倒数
2. MySQL 8.0：wait_timeout 全程倒数，只要没发任何语句（包括 COMMIT），空闲时间一到就 KILL
3. 后果：同样一段“开启事务但未提交”的代码，在 5.7 上能活 8 小时，在 8.0 上几分钟就断——升级版本后掉线暴增，大概率是这原因
4. 兼容做法：无论哪个版本，都在 my.cnf 里强制写死 wait_timeout = 600 和 interactive_timeout = 600，并确保应用层事务绝不跨请求边界

真正难的不是改几个数字，而是让数据库超时、连接池生命周期、应用事务边界三者咬合严丝合缝。少对齐一环，凌晨三点的报警就准时响起。