mysql如何配置连接超时自动断开_调整wait_timeout与interactive

wait_timeout和interactive_timeout控制MySQL服务端对空闲连接的断开时间，前者用于非交互式连接（如JDBC），后者用于交互式连接（如mysql命令行），但5.7+默认均按非交互式处理，实际主要生效的是wait_timeout。

mysql如何配置连接超时自动断开_调整wait_timeout与interactive_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 类机制定期发心跳。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

配置文件里到底怎么写才生效？

在 /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 和应用层的异常捕获重试逻辑。漏掉任何一环，光调这个参数都是治标。