看到 Communications link failure
就该查 wait_timeout
这个错误不是网络断了，而是 MySQL 主动“踢人”了——连接空闲太久，服务端直接断开 TCP 连接。典型表现是：应用启动后前几小时正常，隔夜或低峰期后首次请求就报错，堆栈里带
Last packet sent to the server was X ms ago。根本原因就是 MySQL 的
wait_timeout（默认 28800 秒 = 8 小时）生效了。
wait_timeout控制非交互式连接（比如 Java 应用用 JDBC 建的连接）的空闲超时
interactive_timeout控制交互式连接（如命令行
mysql -u root -p）的空闲超时 二者必须**同时修改**，否则只改一个可能无效（JDBC 连接初始化时会按客户端类型选其一赋值） 别信
autoReconnect=true—— MySQL 5.5+ 已废弃，不解决根本问题，还可能掩盖连接泄漏
永久生效：改 /etc/my.cnf
并重启 mysqld
这是最稳妥、最推荐的做法，尤其在线上环境。临时 SET GLOBAL 只在当前会话生效，MySQL 重启后还原，生产环境不建议依赖。
[mysqld] wait_timeout = 2592000 interactive_timeout = 2592000 net_read_timeout = 600 net_write_timeout = 6002592000 秒 = 30 天，足够覆盖绝大多数业务低峰场景；若担心资源堆积，设为 86400（24 小时）也够用
net_read/write_timeout防止大结果集传输中途卡住被断，和空闲超时无关但常一起调 CentOS/Ubuntu 路径一般是
/etc/my.cnf或
/etc/mysql/my.cnf；Docker 容器需挂载配置文件或进容器改
/etc/mysql/conf.d/*.cnf改完必须执行
systemctl restart mysqld（或
docker restart mysql），不能只 reload
代码层兜底：连接池健康检查比“延长超时”更可靠
光靠调大
wait_timeout是治标。真正健壮的做法，是在应用侧让连接池主动探测并剔除失效连接。Spring Boot + HikariCP 默认就支持，但很多人因为拷贝旧配置关掉了它。 确保
spring.datasource.hikari.connection-test-query=SELECT 1（MySQL 8.0+ 推荐用
SELECT 1，不用
isValid()） 开启连接存活验证：
spring.datasource.hikari.validation-timeout=3000（毫秒） 关键参数：
spring.datasource.hikari.idle-timeout=600000（空闲 10 分钟才回收） +
spring.datasource.hikari.max-lifetime=1800000（连接最多活 30 分钟，强制刷新） MyBatis / JPA 默认不自动 ping，如果用了 Druid，要确认
testWhileIdle=true和
timeBetweenEvictionRunsMillis=30000已启用
排查时先运行这三句 SQL，别急着改配置
很多团队一出问题就改配置、重启库，结果发现其实是连接池没配好，或者某段代码长期持有连接不释放。先快速定位真实瓶颈：
SHOW VARIABLES LIKE 'wait_timeout'; SHOW VARIABLES LIKE 'interactive_timeout'; SHOW STATUS LIKE 'Threads_connected';如果两个 timeout 显示是 28800，说明没改过，大概率就是它 如果
Threads_connected持续接近
max_connections（查
SHOW VARIABLES LIKE 'max_connections'），那不是超时，是连接泄漏 再查慢查询：
SHOW FULL PROCESSLIST;看有没有
Sleep状态且
Time值极大的线程——那是应用没 close() 连接，不是超时
真正麻烦的不是超时本身，而是把超时当成万能借口，忽略了连接池配置错误、事务未提交、流未关闭这些更常见的泄漏源头。
