出现 Communications link failure 报错通常是因为数据库连接池中的连接存活时间超过了 MySQL 服务端设置的超时时间，导致客户端拿到已失效的连接。排查重点在于对比连接池的 maxLifetime 配置与 MySQL 的 wait_timeout 参数，确保池化连接在服务端断开前主动回收。

命令速用版

直接在 MySQL 客户端执行以下 SQL 查看当前超时配置：

SHOW VARIABLES LIKE 'wait_timeout';

SHOW VARIABLES LIKE 'interactive_timeout';

若使用 HikariCP 连接池，检查 application.properties 或 YAML 配置中的 spring.datasource.hikari.max-lifetime 项。

为什么会这样

根本原因是连接池复用机制与 MySQL 服务端空闲回收策略不一致。

MySQL 服务端默认会在连接空闲达到 wait_timeout 设定值后主动断开连接，而连接池默认可能认为连接长期有效。当应用从池中取出一个已被服务端断开的连接执行 SQL 时，就会抛出 Communications link failure。公开资料中没有看到可靠的量化数据说明具体多少并发下必现，但这是长连接场景下的常见现象。

分步处理

第一步：查询 MySQL 服务端超时时间。

使用数据库管理工具或命令行登录 MySQL，执行 SHOW VARIABLES LIKE '%timeout%'。记录 wait_timeout 的数值，单位是秒。默认值通常为 28800 秒（8 小时）。

第二步：检查连接池配置。

找到项目中的数据库连接池配置文件。常见连接池如 HikariCP、Druid、DBCP 均有最大存活时间配置项。例如 HikariCP 对应 maxLifetime，Druid 对应 minEvictableIdleTimeMillis 和 timeBetweenEvictionRunsMillis。

第三步：调整连接池存活时间。

将连接池的最大存活时间设置为小于 MySQL wait_timeout 的值。建议比 wait_timeout 少 30 秒至 60 秒，留出网络传输缓冲。例如 wait_timeout 为 28800，则 maxLifetime 可设为 28740000 毫秒。

第四步：开启连接验证。

配置连接池在借用连接时验证有效性。HikariCP 默认开启，Druid 需配置 testOnBorrow 或 testWhileIdle 为 true，并设置 validationQuery 为 SELECT 1。

怎么验证是否生效

查看应用日志，确认 Communications link failure 错误不再频繁出现。

监控连接池状态，观察活跃连接数是否稳定。若使用 Spring Boot Actuator，可通过 /actuator/metrics/hikaricp.connections 接口查看连接获取情况。

在低峰期观察数据库服务端连接数，确认空闲连接是否按预期被回收。

常见坑

不要将连接池 maxLifetime 设置为 0，这表示无限存活，极易触发超时报错。

注意单位换算，MySQL 超时单位是秒，连接池配置通常是毫秒，配置时需乘以 1000。

若中间有防火墙或负载均衡设备，它们的 TCP 超时策略可能短于 MySQL 设置，需同时排查网络设备配置。

常见问题

wait_timeout 默认值是多少？

MySQL 官方文档指出 wait_timeout 默认值为 28800 秒，但具体值需以实际实例配置为准。

HikariCP 的 maxLifetime 推荐设置多少？

建议设置为比 MySQL wait_timeout 少 30 秒以上，且不要低于 30000 毫秒。

开启 testOnBorrow 会影响性能吗？

会增加每次获取连接的开销，公开资料中没有看到可靠的量化数据说明具体损耗，建议优先调整 maxLifetime 而非依赖每次验证。

重启 MySQL 能解决吗？

重启只能暂时清除当前失效连接，若配置不匹配，问题会在 wait_timeout 周期后复现。

参考来源

• MySQL Official Documentation, Server System Variables, https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html
• HikariCP GitHub Repository, Configuration, https://github.com/brettwooldridge/HikariCP