绝大多数“communications link failure”错误是因mysql服务端主动关闭空闲连接导致僵尸连接被复用；需将wait_timeout（建议300～600秒）与连接池max-lifetime、idletimeout等参数严格对齐，并启用select 1预校验。
绝大多数“Communications link failure”错误，不是网络断了，而是连接被 MySQL 服务端主动关掉了——你拿到的是一条“僵尸连接”。
为什么 wait_timeout 是罪魁祸首
MySQL 默认 wait_timeout=28800（8 小时），但云数据库（如阿里云 RDS、腾讯云 CDB）普遍设为 300～1800 秒（5～30 分钟）。JDBC 连接池里的连接一旦空闲超时，MySQL 服务端就发 EOF 关闭 socket；而连接池没及时感知，下次业务取到这个连接执行 SQL，就会抛出 CommunicationsException，日志里显示 “last packet received … XXX milliseconds ago”。
关键点：
-
wait_timeout控制 JDBC 这类非交互式连接，interactive_timeout不影响你的应用 - 该超时是服务端单向关闭，TCP 状态仍是
ESTABLISHED，所以 ping 得通、telnet 3306 也通，但实际已不可用 - 错误堆栈里出现
com.mysql.cj.jdbc.exceptions.CommunicationsException（注意是cj包），基本可锁定是连接陈旧问题，不是驱动版本或 SSL 配置错
连接池必须开启连接有效性检测
不能只靠调大 wait_timeout，因为云厂商可能随时改；也不能依赖 autoReconnect=true（MySQL 5.5+ 已废弃且不可靠）。
正确做法是在连接池配置中启用预校验：
- HikariCP：设
connection-test-query=SELECT 1+validation-timeout=3000，并确保connection-init-sql或isolate-internal-queries不干扰 - Druid：必须设
test-on-borrow=true（不是test-while-idle），同时validation-query=SELECT 1和validation-query-timeout=3 - 不要设
test-on-return，它会拖慢归还速度，且解决不了“刚借出就失效”的场景
URL 参数里别乱加 usessl 和 serverTimezone
高版本驱动（mysql-connector-java:8.0+）对 URL 参数更敏感，错误组合会掩盖真实问题：
- 如果 MySQL 实例没开 SSL，却在 URL 里写
&useSSL=true，连接会直接失败，报错更早、更明确；但若写成&useSSL=false，反而可能掩盖后续的超时问题 -
serverTimezone必须显式指定（如&serverTimezone=GMT%2B8），否则驱动可能因时区解析失败而静默重连失败 - 避免混用旧参数：
autoReconnect、failOverReadOnly、roundRobinLoadBalance在 8.0+ 驱动中已被移除或无效，留着反而增加排查干扰
别把 localhost 改成 IP 地址来“绕过”问题
有文章说“云服务器上把 jdbc:mysql://123.123.123.123:3306/xxx 改成 jdbc:mysql://localhost:3306/xxx 就不报错了”——这其实是误判。真正起作用的是：本地回环走 Unix socket（Linux）或命名管道（Windows），绕过了 TCP 层的 keepalive 和服务端 wait_timeout 检查。但它只适用于应用和 MySQL 同机部署，且牺牲了监控、审计、流量控制等能力。
这种方案的问题：
- 开发环境用 IP，生产用 localhost，配置不一致，容易引发其他环境问题
- 无法使用云厂商提供的连接池代理、SQL 审计、慢日志分析等能力
- 一旦未来拆库或迁移，要全量改配置，风险集中
真正该做的，是让连接池和 MySQL 的超时策略对齐：连接池最大空闲时间（maxIdleTime 或 idleTimeout）必须小于 MySQL 的 wait_timeout，差值至少留 30 秒余量。
