mysql连接池配置核心是匹配真实负载节奏，需按“并发线程数×平均占用时长”计算池大小，对齐数据库超时参数，启用连接验证与泄漏检测，并通过activecount等指标持续监控调优。
MySQL连接池参数配置的核心目标，是让应用在高并发下既能快速拿到连接，又不压垮数据库。关键不在堆数量，而在匹配真实负载节奏——连接用得快、还得快、别卡住、别失效。
连接池大小要算清楚，不是拍脑袋
最大连接数（maxPoolSize 或 maximumPoolSize）不能只看单机QPS。得结合两个数字：应用并发线程数 × 连接平均占用时长。
- 比如100个后端线程，每个SQL操作平均占连300ms，理论峰值需要约30个活跃连接（100 × 0.3），但需预留缓冲，设为40–50较稳妥
- 若部署了5台应用服务器，每台配50连接，MySQL服务端 max_connections 至少要设到 5×50 + 100 = 350，避免被拒绝
- 空闲连接数（minIdle / minimumIdle）建议设为最大值的20%–50%，保证突发流量有“热连接”可拿，HikariCP默认是max的1/8，常需手动调高
超时设置必须和数据库对齐
连接池的等待超时（connectionTimeout）、连接生命周期（maxLifetime）、空闲连接存活时间（idleTimeout）都要跟MySQL服务端参数呼应。
- connectionTimeout 推荐 3–10 秒：太短容易误抛异常，太长会拖慢接口响应
- maxLifetime 设为 30–60 分钟：比MySQL的 wait_timeout（推荐调至600秒即10分钟）短一点，主动淘汰老化连接，避免被服务端静默断开
- idleTimeout 建议 10–30 分钟：比 maxLifetime 略短，确保空闲连接在失效前被清理，减少无效健康检查
验证与回收机制不能省
连接池不是建完就完事，长期运行中会出现网络闪断、MySQL主动踢连接、事务未提交导致连接卡死等问题。
- 开启连接有效性验证：HikariCP用 connection-test-query=SELECT 1，或启用 isValid() 检查；Druid支持 testWhileIdle + timeBetweenEvictionRunsMillis
- 务必设置 leakDetectionThreshold（如30000毫秒）：检测连接未归还，及时报警定位代码漏写
close()的地方 - 归还连接前重置状态：启用 resetConnectionOnReturn（Druid）或确保自动 rollback + clearWarnings，避免会话变量污染
监控才是调优的起点和终点
没有监控的调优等于盲调。重点关注四个指标：
- activeCount：当前正在用的连接数，持续接近 maxPoolSize 是扩容信号
- idleCount：空闲连接数，长期为0说明池子偏小或连接泄漏
- poolWaitCount：等待获取连接的次数，非零说明有排队，需查是池小还是SQL慢
- createCount / destroyCount：频繁创建销毁说明连接复用率低，可能 maxLifetime 过短或连接泄漏
配合MySQL端看 SHOW STATUS LIKE 'Threads_connected' 和 max_used_connections，交叉验证是否真正打满资源。
