MySQL连接池空闲连接被主动断开主因是wait_timeout与idleTimeout不匹配，需设idleTimeout为wait_timeout的70%～80%，并开启有效性验证；minIdle宜设maximumPoolSize的30%～50%；maxLifetime应比wait_timeout短1～2分钟；驱动需升级至8.x并修正class-name。
连接池空闲连接被 MySQL 主动断开
MySQL 默认 wait_timeout 是 28800 秒（8 小时），但很多中间件或云数据库会设得更短，比如 300 秒。如果 minIdle 设得过大，又长期没请求，大量连接就卡在“空闲但未验证”状态，一被 MySQL kill，下次取出来就直接报 Communications link failure 或 Connection reset。
实操建议：
- 开启连接有效性验证：HikariCP 用
connectionTestQuery=SELECT 1（MySQL 8.0.22+ 推荐isValid()，配connectionInitSql不如用validationTimeout+keepaliveTime） -
idleTimeout必须小于 MySQL 的wait_timeout，建议设为后者的 70%～80%，比如 MySQL 是 300 秒，这里填240000（毫秒） - 避免把
minIdle设成和maximumPoolSize一样大——这等于强制保活所有连接，反而加剧超时风险
HikariCP 的 minIdle 和 maximumPoolSize 差太多会卡住
当 minimumIdle=5、maximumPoolSize=20，但瞬间并发冲到 25，前 20 个能拿到连接，第 21 个开始等；如果 connectionTimeout 只有 30 秒，而数据库响应慢或锁表，就会抛 java.sql.SQLTimeoutException: Timeout after 30000ms of waiting for a connection。
实操建议：
- 压测时重点看
HikariPool-1 - After adding 5 connections, pool total is 20这类日志，确认扩容是否及时触发 - 线上建议
minimumIdle设为maximumPoolSize的 30%～50%，例如最大 40，最小至少 12～20，留出缓冲空间 - 别迷信“小 minIdle 节省资源”——连接重建开销远大于空闲几条连接的内存，尤其 TLS 握手+SSL 加密场景下
Spring Boot 2.3+ 默认 Hikari 配置不兼容老 MySQL 驱动
Spring Boot 2.3 开始默认启用 autoCommit=false 初始化连接，但 MySQL Connector/J 5.1.x 在某些低版本（如 5.1.23）里对 setAutoCommit(false) 响应异常，导致连接池初始化失败，日志出现 Unable to set auto-commit mode on JDBC Connection。
实操建议：
- 升级驱动：MySQL 5.7 用
mysql:mysql-connector-java:8.0.33，MySQL 8.0+ 必须用 8.x 驱动 - 临时绕过：加配置
spring.datasource.hikari.initialization-fail-timeout=-1（跳过初始化验证），但只是掩盖问题 - 检查
driver-class-name是否写成com.mysql.jdbc.Driver（已弃用），应改为com.mysql.cj.jdbc.Driver
maxLifetime 设太长导致连接老化失效
maxLifetime 是连接从创建起能活多久，单位毫秒。设成 1800000（30 分钟）看似稳妥，但如果数据库做了主从切换、Proxy 重启或防火墙策略变更，这个“还活着”的连接其实已经无法通信，但池子不知道，仍会分配出去，结果就是随机性 Unknown initial character set index 或 Packets out of order。
实操建议：
-
maxLifetime应比数据库侧连接最大存活时间短至少 1～2 分钟，例如 MySQLwait_timeout=300，这里最多设240000（4 分钟） - 配合
leakDetectionThreshold（比如60000）一起开，能快速发现连接未归还问题 - 别依赖
maxLifetime当兜底——它只管“年龄”，不管“健康”，真正防失效还得靠validationTimeout+keepaliveTime
最麻烦的不是参数调不对，而是不同环境的 MySQL 实例配置不一致：开发用本地 Docker MySQL，wait_timeout 是默认 28800；测试环境 RDS 是 300；生产又套了 Proxy，中间加了连接复用层。同一套 application.yml 往往在某个环节突然崩，查半天才发现是连接池在替别人背 timeout 锅。
