MySQL空闲连接断开后首条SQL变慢，本质是连接重建开销：TCP重连+SSL握手+认证+会话初始化耗时100–500ms；根本原因在于连接池未及时感知MySQL服务端wait_timeout主动断链，导致复用已失效连接。
MySQL空闲连接断开后首条SQL变慢，本质是连接重建开销
这不是 SQL 本身变慢，而是应用拿到一个已被 MySQL 主动关闭的连接（wait_timeout 触发），却误以为它还活着。当执行第一条 SELECT 或 INSERT 时，驱动层才发现连接已断，不得不走完整的 TCP 重连 + SSL 握手 + 认证 + 初始化会话流程，整个过程耗时通常在 100–500ms，远超正常查询的几毫秒。
为什么连接池没提前发现连接已失效？
很多连接池（如 HikariCP 默认、Druid 未开启检测）不会在每次 getConnection() 前校验连接可用性，只依赖“连接空闲时间 maxLifetime”或“是否超时”这类静态判断。而 MySQL 的 wait_timeout 是服务端主动断链，客户端 TCP 层可能仍显示 ESTABLISHED（尤其在无数据交互时），导致连接池误判。
-
testOnBorrow=true（已废弃）或connectionTestQuery=SELECT 1在旧版 Druid 中有效，但会增加每次获取连接的 RT - HikariCP 推荐用
connectionInitSql=SELECT 1或启用keepaliveTime（需 MySQL 5.7+、驱动 8.0.22+） - 更可靠的是开启
validationTimeout+connectionTestQuery，但注意该 SQL 必须轻量、不触发权限检查（避免SELECT NOW()因时区权限失败）
autoReconnect=true 会让首条 SQL 变快吗？
不会，反而更不可控。这个参数不是“自动续命”，而是“断了就换新连接”，且发生在 SQL 执行过程中：驱动捕获到通信异常后，才发起重连并重试当前语句。这意味着：
- 原事务已回滚，
SET @var := 1这类会话变量丢失 - 锁被释放，可能引发业务逻辑错乱（比如库存扣减重复）
- 重试机制不保证幂等，
INSERT可能被执行两次 - MySQL 官方文档明确标注
autoReconnect已弃用，不推荐生产使用
真正有效的保活策略组合
靠单一配置无法根治，必须服务端、驱动层、连接池三层对齐：
- MySQL 侧：把
wait_timeout和interactive_timeout统一设为 7200（2 小时），避免过长空闲；修改位置是/etc/my.cnf的[mysqld]段，改完需sudo systemctl restart mysql - 连接池侧：HikariCP 设置
maxLifetime=600000（10 分钟）、keepaliveTime=30000（30 秒），确保连接在 MySQL 断开前就被池子主动淘汰或心跳保活 - 驱动侧：JDBC URL 加
?socketTimeout=30000&connectTimeout=3000，防止底层阻塞掩盖真实问题
最易被忽略的是 keepaliveTime 依赖 MySQL 的 tcp_keepalive 内核参数和驱动版本——如果用的是 MariaDB Connector/J 或老版 MySQL Connector/J 5.1，这个参数根本不起作用。
