答案：根本原因是mysql服务端wait_timeout与客户端sockettimeout不匹配且未启用连接有效性检测；需同步调整服务端wait_timeout/interactive_timeout、jdbc sockettimeout及连接池validationquery等参数，并排查dns解析、认证插件和云厂商slb超时等干扰因素。
不是连接后“立即”断开，而是连接建立成功、但首次执行 SQL 时抛出 Communications link failure 或 The last packet successfully received from the server was ... ago —— 这说明连接在空闲期已被 MySQL 服务端静默关闭，而客户端（或连接池）没做有效性检测，直接复用了这个“僵尸连接”。
MySQL 8.0 的 wait_timeout 默认值是 28800 秒（8 小时），但云环境 SLB/防火墙常设 5 分钟超时
很多团队误以为“本地跑通=线上没问题”，结果上线后每 5–6 分钟就报一次连接失败。根本原因不是 MySQL 自己断的，是中间网络设备（如阿里云 SLB、AWS ALB、K8s Service）比 MySQL 更早清理空闲连接。MySQL 的 wait_timeout 在这里只是“底线”，实际生效的是链路中最短的那个超时阈值。
- 查当前服务端设置：
SHOW VARIABLES LIKE 'wait_timeout';和SHOW VARIABLES LIKE 'interactive_timeout'; - 云厂商 SLB 默认空闲超时多为 300–600 秒，且无法从 MySQL 侧感知或覆盖
- 如果你用 Docker 或 Kubernetes，Service 的 connection tracking timeout 也可能干扰（尤其 iptables 模式）
连接池没开 validationQuery 或 testWhileIdle，导致复用失效连接
Druid、HikariCP、DBCP2 都默认不主动探测连接是否还活着。哪怕你配了 testOnBorrow=true，MySQL 8.0+ 的 caching_sha2_password 认证机制下，SELECT 1 可能被缓存或跳过握手，实际起不到验证作用。
- Druid 必须同时配：
validationQuery=SELECT 1+testWhileIdle=true+timeBetweenEvictionRunsMillis=30000 - HikariCP 不支持
validationQuery，要用connection-test-query=SELECT 1（8.0+ 推荐改用isValid()调用，但需驱动版本 ≥ 8.0.28） - Spring Boot 2.4+ 的 HikariCP 默认禁用
connection-test-query，必须显式开启
JDBC URL 缺少 socketTimeout，长查询被客户端单方面中断
错误日志里出现 “during query” 或 “during result set read”，大概率是 socketTimeout 太小。它和 wait_timeout 完全无关：前者控制单次 I/O 等待上限，后者控制空闲连接存活时间。
- MySQL JDBC 默认
socketTimeout=0（无限等待），但生产环境绝不能依赖这个 - 远程执行复杂 SQL 时，设
socketTimeout=600000（10 分钟）比设 30 秒更合理 - 必须配合连接池的
max-lifetime（如 HikariCP 的max-lifetime=1800000）小于 MySQL 的wait_timeout，否则连接池会把“将死未死”的连接继续分发
真正容易被忽略的点：MySQL 8.0 默认启用 caching_sha2_password 插件，旧版 JDBC 驱动（mysql-connector-java ）在复用连接时可能因认证上下文丢失而静默失败，现象就是连接看似正常、一查就崩——换 <code>com.mysql.cj.jdbc.Driver 并确认驱动版本 ≥ 8.0.28 才算闭环。
