wait_timeout和interactive_timeout控制MySQL服务端对空闲连接的断开时间，前者用于非交互式连接（如JDBC），后者用于交互式连接（如mysql命令行），但5.7+默认均按非交互式处理，实际主要生效的是wait_timeout。
wait_timeout 和 interactive_timeout 到底管谁？
这两个参数控制的是 MySQL 服务端主动关闭空闲连接的时间，不是客户端连接失败的超时（比如 connect_timeout），也不是查询执行超时（那是 max_execution_time）。简单说：连接建好了、没在跑 SQL、干等着——等多久就断你。
关键区别在于：wait_timeout 作用于非交互式连接（比如应用服务器用 JDBC/PHP PDO 建的连接），interactive_timeout 作用于交互式连接（比如你敲 mysql -u root -p 进去的命令行会话）。但注意：MySQL 5.7+ 默认把新连接都按非交互式处理，除非客户端显式声明 CLIENT_INTERACTIVE 标志——而绝大多数 ORM、连接池（如 HikariCP、Druid）都不设这个标志，所以实际生效的几乎总是 wait_timeout。
怎么查当前值？别只看 SHOW VARIABLES
SHOW VARIABLES LIKE '%timeout%' 看到的是全局默认值，但每个连接启动时会从全局复制一份作为自己的会话级超时。真正决定当前连接几秒后断开的，是会话变量：
SELECT @@wait_timeout, @@interactive_timeout;
如果你用连接池，建议在池配置里加一条初始化 SQL（如 connection-init-sql=SET SESSION wait_timeout = 600），比改全局更安全——避免影响 DBA 的运维连接或其它应用。
- 全局修改需
SET GLOBAL wait_timeout = 600，但要求 SUPER 权限，且重启后丢失（除非写进配置文件） - 配置文件中设置要区分 [mysqld] 和 [client] 段：只有 [mysqld] 下的
wait_timeout才生效；[client] 下的无效 - 某些云数据库（如阿里云 RDS、腾讯云 CDB）禁止修改全局 timeout 参数，只能靠连接池侧控制
调小 wait_timeout 容易引发什么问题？
最典型的是「MySQL server has gone away」错误，尤其发生在连接池长期持有空闲连接、但应用没做保活或重连时。例如：
- Spring Boot + HikariCP 默认
connection-timeout=30000（30 秒），但若wait_timeout=60（1 分钟），而连接池里的连接 45 秒没用，它不会主动断开，等到第 61 秒首次复用时才报错 - Django 的
CONN_MAX_AGE设为 0 表示不复用连接，反而避开这个问题；设为非 0 时就得确保小于wait_timeout - PHP 的
mysqli长连接（mysql_pconnect）在 Apache prefork 模式下可能复用进程内的连接，超时后下次请求直接失败
解决思路不是一味调大 wait_timeout，而是让连接池自己管理生命周期：启用 validation-query（如 SELECT 1）和 test-on-borrow，或者用 keepalive-timeout 类机制定期发心跳。
配置文件里到底怎么写才生效？
在 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf 的 [mysqld] 段添加：
[mysqld] wait_timeout = 300 interactive_timeout = 300
注意：单位是秒，不是毫秒；两个值设成一样可减少混淆；设太小（如 30）可能让低频后台任务频繁重连；设太大（如 28800 即 8 小时）会导致大量僵尸连接堆积，尤其当应用没正确 close 连接时。
改完必须重启 MySQL（systemctl restart mysql），仅 reload 不生效。验证是否加载成功：登录后执行 SELECT @@wait_timeout;，结果应与配置一致。
真实环境里，wait_timeout 很少单独调优——它只是连接健康度链条上的一环。更关键的是连接池的 max-lifetime、idle-timeout 和应用层的异常捕获重试逻辑。漏掉任何一环，光调这个参数都是治标。
