wait_timeout是MySQL服务端对非交互式连接空闲超时断开的秒数，默认通常为28800秒（8小时），影响JDBC等应用连接，需与连接池配置协同调整以避免“MySQL server has gone away”错误。
wait_timeout 是什么，为什么改它
wait_timeout 控制的是 MySQL 服务端对**非交互式连接**（比如应用通过 JDBC、PDO 建立的连接）在空闲状态下保持打开的最长时间。超时后，服务端会主动断开连接，下次再用这个连接就会报 MySQL server has gone away 或 Lost connection to MySQL server during query。它和 interactive_timeout 是分开的，后者只影响 mysql 客户端这类交互式连接。
怎么查看当前值
连上 MySQL 后直接查：
SELECT @@wait_timeout, @@interactive_timeout;
返回单位是秒，默认通常是 28800（即 8 小时）。注意：不同发行版或云数据库（如阿里云 RDS、腾讯云 CDB）可能默认值不同，有的甚至设为 300 秒（5 分钟）来强制连接池回收。
修改 wait_timeout 的三种方式
修改生效范围和持久性差异很大，选错容易白改：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
会话级临时修改（仅当前连接）：
SET SESSION wait_timeout = 600;
—— 断开重连就失效，适合调试，不影响其他连接 -
全局动态修改（重启失效）：
SET GLOBAL wait_timeout = 600;
—— 影响后续新建的所有连接，但 MySQL 重启后恢复配置文件里的值 -
永久修改（需改配置文件）：编辑
my.cnf或mysqld.cnf，在[mysqld]段落下加：wait_timeout = 600<br>interactive_timeout = 600
—— 必须重启 MySQL 才生效，且建议两个变量值设成一致，避免行为不一致
改了之后要注意什么
不是设小了就万事大吉，关键得和客户端配合：
- 连接池（如 HikariCP、Druid）必须开启
testOnBorrow或配置validationQuery（例如SELECT 1），否则拿了个已断开的连接直接报错 - 如果设成 300 秒，但应用里连接池的
maxLifetime设成了 1800000（30 分钟），那连接大概率在被回收前就被 MySQL 先断了 - 云数据库有些不支持
SET GLOBAL，只能走控制台参数模板或工单修改，且可能限制最小值（如 AWS RDS 强制 ≥ 60 秒） -
wait_timeout不影响正在执行的查询，只作用于“完全没发请求”的空闲期；长事务或慢查询不会因此被杀
真正要稳，得让 MySQL 的断开时间略大于连接池的连接最大存活时间，并确保连接池有探活机制——光调 MySQL 参数只是半步。
