MySQL 数据库连接池 HikariCP 调优实践

MySQL连接池调优需综合计算大小、严控超时、协同空闲保活、启用泄漏检测：按CPU核数×2+磁盘数估算基础值，联动max_connections与实例数确定上限；connectionTimeout设2–5秒，idleTimeout略小于DB wait_timeout；minimumIdle=maximumPoolSize，keepaliveTime略小于idleTimeout；leakDetectionThreshold生产设60秒，禁用testOnBorrow改用SELECT 1定期验证。

MySQL 连接池不是配个 maximumPoolSize 就完事的。调优的关键在于让连接池真正“活”起来——既不卡住请求，也不空转浪费，更不拖垮数据库。

连接池大小不能拍脑袋定

设 500 个连接看似保险，实则危险：MySQL 每个连接约占用 2–4MB 内存，500 个就是 1–2GB；同时高并发下锁争用加剧，QPS 反而下降。官方推荐公式适用于 OLTP 场景：

• CPU 核数 × 2 + 磁盘数（例如 8 核 + 1 磁盘 → 推荐 17 左右）
• 若存在长查询或存储过程，可放大至 3–5 倍，但一般不超过 100
• 必须联动数据库 max_connections 和应用实例数：比如 DB 允许 900 连接、部署 3 台服务，单机建议 ≤ 250，再留 20% 余量 → 实际设 200 较稳妥
• 用 QPS × P95 SQL 耗时验证下限：若 QPS=300、P95=120ms，则理论最小需 36 个连接，设 50 是安全起点

超时参数必须严控

默认 connectionTimeout=30000（30 秒）太长，用户早关页面了。线上应压到 1–3 秒，避免线程长时间挂起：

• connectionTimeout：设为 2000–5000 毫秒，超时快速失败
• validationTimeout：必须 ≤ MySQL 的 wait_timeout（如 DB 设 300 秒，这里不能超 300000）
• idleTimeout：默认 10 分钟（600000ms），若 DB 侧超时是 5 分钟，建议设为 240000（4 分钟），防止连接被静默断开后仍被复用

空闲与保活策略要协同

空闲连接频繁创建销毁，说明池子没稳住。根本原因常是 minimumIdle 过低或 idleTimeout 过短：

• minimumIdle 建议设为和 maximumPoolSize 相同（如都设 20），避免冷启动抖动；设为 0 时实际不维持任何空闲连接
• keepaliveTime（HikariCP ≥ 3.2.1）设为比 idleTimeout 小一点（如 idle=240000，keepalive=200000），主动发心跳保活，防中间设备或 DB 层 silent kill
• maxLifetime 建议设为 1800000（30 分钟），略小于 DB 的 wait_timeout，避免连接因老化失效

泄漏与验证机制要打开

连接不归还，池子再大也白搭。必须靠机制兜底：

• 开发环境启用 leakDetectionThreshold=10000（10 秒），能立刻暴露未 close 的 ResultSet/Statement
• 生产环境可设为 600000（10 分钟），兼顾灵敏度与误报率
• 禁用已废弃的 testOnBorrow，改用 connectionTestQuery=SELECT 1 + idleValidationMinutes=5，空闲 5 分钟检测一次，轻量可靠
• 确认 initializationFailTimeout 不为阻塞型（默认 -1 即可），避免启动失败卡死