mysql连接超时怎么处理_mysql超时异常排查方法

Communications link failure 根本原因是 MySQL 的 wait_timeout（默认 8 小时）主动断开空闲连接，非网络故障；需同步调整 wait_timeout 和 interactive_timeout，并配合连接池健康检查（如 HikariCP 的 validation-timeout 和 max-lifetime）治本。

看到 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 = 600

• 2592000 秒 = 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() 连接，不是超时

真正麻烦的不是超时本身，而是把超时当成万能借口，忽略了连接池配置错误、事务未提交、流未关闭这些更常见的泄漏源头。