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 = 600interactive_timeout = 600
注意点：
不要加引号、不要写单位（如 s 或 sec），只写纯数字（单位固定为秒）修改后必须重启 MySQL：Linux 上用 sudo systemctl restart mysql 或 sudo service mysqld restart；Docker 容器需 docker restart <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" 查实际读取路径。
评论(0)