是，MySQL连接突然断开很可能是wait_timeout在作怪；它控制非交互式连接空闲超时（默认28800秒），超时后服务器主动断开，但需配合客户端心跳与合理参数协同调优。
MySQL连接突然断开，是不是wait_timeout在作怪？
绝大多数“连接被服务器关闭”“MySQL server has gone away”这类报错，根源就是wait_timeout默认值太保守（通常为28800秒，即8小时——看似很长，但对长轮询、慢查询或空闲连接池很危险）。它控制的是**非交互式连接**（比如应用通过JDBC/PHP PDO建立的连接）空闲多久后被服务端主动断开。
- 交互式连接（如
mysql命令行）受interactive_timeout控制，两者默认值可能不同，别混用 - 修改
wait_timeout只影响新建立的连接，已存在的连接仍按旧值计时 - 不能只调大就完事：设成数天会堆积大量僵尸连接，拖慢
SHOW PROCESSLIST，甚至触发max_connections上限
怎么安全地调整wait_timeout参数？
直接改配置文件（my.cnf）最稳妥，但需重启MySQL；运行时临时调整仅对当前会话有效，且不推荐用于生产环境长期依赖。
- 永久生效：在
[mysqld]段下添加wait_timeout = 3600（建议1~2小时，兼顾空闲释放与业务容忍度） - 验证是否生效：
SELECT @@wait_timeout;（注意是会话级变量，要查全局值用SELECT @@global.wait_timeout;） - 别碰
interactive_timeout除非你真在改命令行行为——应用连接几乎全是非交互式 - 如果用的是云数据库（如阿里云RDS、AWS RDS），部分平台禁止修改该参数，得靠客户端侧保活
客户端不配心跳，光调wait_timeout等于白干
很多框架（如Spring Boot + HikariCP、Laravel + PDO）默认不开启连接有效性检测，导致连接池里存着已被MySQL悄悄断开的“假连接”，下次取出来就直接报错。
- HikariCP必须配
connection-test-query=SELECT 1（MySQL 8.0.19+ 改用connection-init-sql）和validation-timeout=3000 - PHP PDO需启用
PDO::ATTR_EMULATE_PREPARES并配合PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION，再在连接前执行SELECT 1 - Node.js mysql2 可设
pingOnConnect: true或在acquireConnectionTimeout内做显式connection.ping() - 别依赖
autoReconnect=true（MySQL官方已弃用，且不可靠）
为什么有些连接超时根本不是wait_timeout的问题？
看到“gone away”，第一反应别急着调wait_timeout。更常见的其实是max_allowed_packet超限（大BLOB/TEXT插入失败）、网络中间件（如Nginx、HAProxy）主动断连、或客户端自身TCP keepalive未开启。
- 查错误日志：
grep "Aborted connection" /var/log/mysql/error.log，带because of an error通常是包大小或权限问题 - 确认网络层超时：用
tcpdump抓包看FIN/RST是否由代理或防火墙发出 - 检查客户端TCP设置：Java应用需确保
socketTimeout>wait_timeout，否则JDBC先断开，MySQL还蒙在鼓里 -
net_read_timeout和net_write_timeout控制单次读写阻塞时长，大结果集导出失败常卡在这俩上
真正难处理的是混合场景：连接池空闲时间、SQL执行耗时、网络抖动、应用重试逻辑全搅在一起。这时候单点调参意义不大，得把wait_timeout、连接池最小空闲数、心跳频率、SQL超时这四者对齐——少一个，都可能让“超时”变成玄学问题。
