必须同时设置wait_timeout和interactive_timeout且值相等，因应用连接属非交互式，仅受wait_timeout控制；仅改interactive_timeout无效。
interactive_timeout 和 wait_timeout 到底该设哪个
如果你只改 interactive_timeout，而没同步改 wait_timeout，绝大多数应用（比如 Java 的 JDBC、Python 的 pymysql、Node.js 的 mysql2）仍然会触发 MySQL server has gone away 错误。因为这些客户端建立的是**非交互式连接**，只受 wait_timeout 控制；interactive_timeout 仅影响 MySQL Shell、mysql 命令行这类人工登录的会话。
所以真实场景中：两个值必须设成一致，且都生效才安全。
-
wait_timeout是你真正要调的参数，它管应用连接 -
interactive_timeout必须同步设置，否则 MySQL 内部逻辑可能因两者不一致导致意外行为（例如新连接继承了错误的默认值） - 云数据库（如阿里云 RDS、腾讯云 CDB）常把
wait_timeout默认设为 300 秒，比本地 MySQL 的 28800 秒激进得多，务必先SHOW VARIABLES LIKE 'wait_timeout';确认当前值
在 my.cnf 里怎么写才真正生效
直接往 /etc/my.cnf 或 /etc/mysql/my.cnf 文件末尾追加配置是常见错误——如果文件里已有 [mysqld] 段落，新配置必须放在该段落下，否则会被忽略。
正确写法示例：
[mysqld] wait_timeout = 600 interactive_timeout = 600
注意点：
- 不要加引号、不要写单位（如
s或sec），只写纯数字（单位固定为秒） - 修改后必须重启 MySQL：Linux 上用
sudo systemctl restart mysql或sudo service mysqld restart；Docker 容器需docker restart <container_name></container_name> - 改完不重启 = 白改；重启后不验证 = 不知道有没有生效
改完为什么还是报 “has gone away”
最常见原因是：MySQL 层面的超时设置只是半步，应用层连接池没配合好。
比如 HikariCP 默认 maxLifetime 是 1800000ms（30 分钟），若你把 wait_timeout 设成 600 秒（10 分钟），但连接池没开启探活（connection-test-query 或 validation-timeout），旧连接在第 11 分钟被复用时仍会失败。
关键协同点：
- 连接池的连接最大存活时间（如 HikariCP 的
maxLifetime）应略小于 MySQL 的wait_timeout（建议留 30–60 秒余量） - 连接池必须启用连接有效性检测（例如
test-on-borrow或validation-query），不能只靠超时被动回收 - 某些 ORM（如 Django ORM）默认不校验连接，需显式配置
CONN_MAX_AGE = 0或启用OPTIONS['init_command']发心跳
验证是否生效的三步检查法
别只信配置文件或重启动作，必须实测确认：
第一步：登录 MySQL 执行
SHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'interactive_timeout';
第二步：检查输出值是否和配置文件里的一致，且两个值相等；
第三步：模拟空闲——用 mysql -u user -p 连上，执行 SLEEP(610);（比你设的 600 秒多 10 秒），再执行任意查询，看是否报错 Lost connection to MySQL server during query。
容易被忽略的细节：MySQL 配置加载顺序复杂，my.cnf 可能被多个路径的同名文件覆盖（如 /etc/mysql/conf.d/ 下的文件），用 mysqld --help --verbose | grep "Default options" 查实际读取路径。
