MySQL连接超时由服务端wait_timeout和interactive_timeout参数控制，前者管非交互式连接（如JDBC），后者管带CLIENT_INTERACTIVE标志的交互式连接；两者值不一致会导致同一应用中部分连接早断、部分晚断，故须统一设置并匹配连接池max-lifetime。
MySQL 的连接超时不是客户端决定的，而是由服务端的 wait_timeout 和 interactive_timeout 两个参数控制的；设错一个，应用就可能偶发断连。
为什么有些连接 10 分钟就断，有些却能活 8 小时？
根本原因在于 MySQL 区分了「交互式」和「非交互式」连接类型，并分别用不同参数控制空闲超时：
-
wait_timeout管非交互式连接——绝大多数应用（JDBC、Python 的 pymysql、Node.js 的 mysql2）默认走这个路径 -
interactive_timeout只管带CLIENT_INTERACTIVE标志的连接——比如mysql -u root -p --interactive启动的命令行，或某些 ORM（旧版 Hibernate）/驱动（PyMySQL 在特定配置下）误设标志的情况 - 两者默认都是 28800 秒（8 小时），但一旦值不一致，同一套应用里就可能出现部分连接 5 分钟断、部分 30 分钟断的诡异现象
怎么查当前生效的超时值？
别猜，直接查服务端实际变量：
SHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'interactive_timeout';
注意：SHOW VARIABLES 返回的是当前会话看到的值，它可能来自全局设置，也可能被会话级 SET SESSION 覆盖。真正影响新连接的是全局值：
- 运行
SELECT @@global.wait_timeout;确认全局设定 - 检查是否被配置文件覆盖：在
my.cnf或my.ini的[mysqld]段里搜wait_timeout和interactive_timeout - 如果配置文件没写，而你又执行过
SET GLOBAL wait_timeout = 600，那重启后这个设置就丢失了
临时改 vs 永久改，选哪个？
临时改只对之后新建的连接生效，已存在的连接仍按旧值计时；永久改必须写进配置文件并重启服务：
- 临时改（调试用）：
SET GLOBAL wait_timeout = 600;和SET GLOBAL interactive_timeout = 600;—— 需要SUPER权限 - 永久改：在
my.cnf的[mysqld]下加两行：wait_timeout = 600interactive_timeout = 600
然后systemctl restart mysqld（或对应服务名） - 切记：两个值必须设成一样，否则容易因连接类型判断偏差导致行为分裂
应用层不配，光调服务端也没用
服务端超时只是“空闲断连”，它不管连接建立阶段卡住或查询跑太久：
-
connect_timeout控制 TCP 连接建立阶段最大等待秒数（默认 10），需在配置文件里设，或 JDBC URL 加connectTimeout=5000 -
max_execution_time才管单条SELECT最长跑多久（毫秒级），例如SET SESSION max_execution_time = 30000; - 连接池（如 HikariCP、Druid）必须同步配
connection-timeout、idle-timeout、max-lifetime，否则池子里的连接可能比服务端还早被干掉
最常被忽略的一点：interactive_timeout 实际上极少被应用触发——除非你明确传了 CLIENT_INTERACTIVE 标志。多数断连问题根源其实是 wait_timeout 设得太小，又没配好连接池的 max-lifetime 去主动淘汰老化连接。
