“communications link failure”多因mysql服务端静默关闭空闲连接导致，连接池未及时检测失效连接所致；需配置testonborrow/testwhileidle（druid）或connection-init-sql/idle-timeout（hikaricp）等健康检查参数，并禁用已废弃的autoreconnect=true。
绝大多数“Communications link failure”在连接池场景下，不是网络断了，而是连接被MySQL服务端静默关闭了——你拿的是一条“僵尸连接”。
为什么连接池会拿到失效连接
MySQL 服务端默认用 wait_timeout（非交互式连接）控制空闲连接寿命，Linux 默认 28800 秒（8 小时），但云数据库（如阿里云 RDS、腾讯云 CDB）普遍设为 300–1800 秒。而连接池（如 HikariCP、Druid）若未主动探测连接有效性，就会把已超时的连接继续分配给业务代码。
此时 TCP 连接仍处于 ESTABLISHED 状态（netstat -an | grep :3306 可见），但 MySQL 已关闭逻辑会话。应用一执行 execute() 或 executeQuery()，立刻抛出 CommunicationsException，错误信息里 The last packet successfully received from the server was XXX milliseconds ago 的毫秒数，往往接近 wait_timeout 值。
- Druid 默认不开启空闲连接校验，
testWhileIdle=false，且timeBetweenEvictionRunsMillis默认为 -1（不启用驱逐线程） - HikariCP 默认启用连接存活检测，但依赖
connection-test-query（旧版）或connection-init-sql（新版），若未显式配置或驱动不支持，实际可能跳过验证 - MyBatis + Druid 组合下，常见于凌晨低流量后首个请求触发异常，本质是连接池未及时剔除陈旧连接
必须配置的连接池健康检查参数
不能只靠调大 wait_timeout —— 云环境不允许，且治标不治本。关键是在连接被业务使用前做有效性验证。
以主流池为例：
Druid：必须显式启用并调参
-
testOnBorrow=true：每次从池中借连接时验证（有性能损耗，适合低并发） -
testWhileIdle=true+timeBetweenEvictionRunsMillis=30000：空闲连接每 30 秒检测一次（推荐） -
validationQuery=SELECT 1：验证 SQL，MySQL 8.0+ 推荐用SELECT 1，避免兼容性问题 -
minEvictableIdleTimeMillis=60000：连接空闲超 60 秒即纳入可驱逐范围（应略小于wait_timeout）
HikariCP：新版（5.0+）推荐用 connection-init-sql 替代已废弃的 connection-test-query
connection-init-sql=SELECT 1-
connection-timeout=30000（非连接池超时，是获取连接的等待上限） -
idle-timeout=600000（空闲连接最大存活时间，建议设为wait_timeout * 0.8） -
max-lifetime=1800000（连接最大生命周期，强制刷新，防长期泄漏）
别再用 autoReconnect=true
autoReconnect=true 在 MySQL Connector/J 5.1.39+ 已被标记为 deprecated，8.0+ 完全移除。它无法解决连接池场景下的问题，因为：
- 重连发生在底层 socket 层，不通知连接池，池内仍持有原失效连接引用
- 重连后语句不会自动重试，上层业务仍收到异常
- 可能掩盖真实问题，导致连接泄漏或事务状态错乱
如果你在 URL 里还带着 ?autoReconnect=true&failOverReadOnly=false，请立刻删掉。这不是解决方案，是埋雷。
MySQL 侧配合调整（仅限可控环境）
如果你能修改 MySQL 配置（如自建库），可微调两个参数降低误判概率，但不能替代连接池侧验证：
-
wait_timeout=14400（4 小时）比默认 8 小时更稳妥，又不至于设到 31536000（一年）导致资源滞留 -
interactive_timeout不用动，JDBC 连接默认是非交互式 - 切勿设
wait_timeout=0：MySQL 实际按最小值 1 秒处理，反而加速断连
注意：云数据库（RDS）通常禁止修改 wait_timeout，只能靠连接池侧应对。
最易被忽略的一点：连接池的 validationQuery 或 connection-init-sql 必须是轻量、无副作用、全版本兼容的语句。用 SELECT VERSION() 或带事务的语句，在某些驱动版本或隔离级别下会失败；SELECT 1 是目前最安全的选择。别图省事复用业务 SQL 做校验。
