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 即可），避免启动失败卡死
