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，导致全局值被覆盖。
必须一次性查全：
-
SELECT @@wait_timeout, @@interactive_timeout;—— 看当前会话实际值 -
SHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'interactive_timeout';—— 看全局默认值 - 如果两个结果不一致，说明客户端或驱动改过会话级变量，
wait_timeout很可能已被“悄悄覆盖”
HikariCP 必须显式配有效性检测，否则永远不知道连接已死
Spring Boot 2.3+ 默认关闭连接有效性验证，spring.datasource.hikari.connection-test-query 不再自动 fallback 到 SELECT 1，不配就等于裸奔。
- 开发/测试环境：开
test-on-borrow=true+connection-test-query=SELECT 1 - 生产环境：禁用
test-on-borrow（性能损耗大），改用test-while-idle=true+validation-timeout=3+idle-timeout=600000 -
maxLifetime必须比 MySQL 的wait_timeout小至少 60 秒，例如 MySQL 设为 600，HikariCP 就设max-lifetime=540000
云数据库改 timeout 要走控制台，且不能只改一个参数
阿里云 RDS、腾讯云 CDB、AWS RDS 都不让你碰 my.cnf，SET GLOBAL 也基本无效（权限受限或重启即丢）。
- 必须进控制台 → 找「参数模板」→ 修改
wait_timeout和interactive_timeout两个值 → 绑定到实例并重启（部分云厂商支持热加载，但需确认） - 云平台常有取值范围限制（如最小 10 秒、最大 31536000 秒），设成 0 是无效的
- 别只调大
wait_timeout却忽略interactive_timeout：哪怕你用的是 Java 应用，某些 JDBC 驱动（如旧版 mysql-connector-java）仍会按交互式逻辑协商，两个值不等就容易错杀
MySQL 5.7 和 8.0 对事务中空闲计时的行为完全不同
这个差异极隐蔽，但直接决定“卡在 BEGIN 后的连接会不会被干掉”。
- MySQL 5.7：
wait_timeout计时器在事务中暂停，BEGIN后不执行语句也不倒数 - MySQL 8.0：
wait_timeout全程倒数，只要没发任何语句（包括COMMIT），空闲时间一到就 KILL - 后果：同样一段“开启事务但未提交”的代码，在 5.7 上能活 8 小时，在 8.0 上几分钟就断——升级版本后掉线暴增，大概率是这原因
- 兼容做法：无论哪个版本，都在
my.cnf里强制写死wait_timeout = 600和interactive_timeout = 600，并确保应用层事务绝不跨请求边界
真正难的不是改几个数字，而是让数据库超时、连接池生命周期、应用事务边界三者咬合严丝合缝。少对齐一环，凌晨三点的报警就准时响起。
