连接池参数需匹配实际负载，关键调优maxactive、minidle、connectiontimeout；数据库max_connections须合理设置并考虑内存占用；应用端需结合qps、持有时间、硬件资源估算连接数；超时与验证必须配对，监控指标不可或缺。
连接池参数配得不对，不是数据库扛不住，就是应用卡死在等连接上。关键不是套模板，而是让 maxActive、minIdle、connectionTimeout 这几个值跟你的实际负载对得上。
先搞清数据库端能撑多少并发连接
应用层连得再猛，数据库也得接得住。MySQL 的 max_connections 是硬上限，超出直接报 Too many connections。默认 151，生产环境基本不够用。
- 查当前值：
show variables like 'max_connections'; - 临时调高（重启失效）：
set global max_connections = 1000; - 持久化修改：在
/etc/my.cnf的[mysqld]段加一行max_connections = 1000 - 别盲目拉高——每个连接约占用 256KB~1MB 内存，1000 连接可能吃掉 1GB+ 内存，得看服务器实际余量
- 多实例部署时，总连接数 ≈ 容器数 × 单容器
maxActive+ 预留 buffer（比如 +100）
应用端连接池大小不能只看 QPS
maxActive（或 maximumPoolSize）不是“我每秒有 200 请求，就设 200”。它得结合连接平均持有时间、数据库吞吐瓶颈、线程模型一起算。
- 粗略估算公式：
(CPU核心数 × 2) + 磁盘数，这是数据库端能高效处理的并发连接参考上限 - 如果应用平均每个请求占连接 200ms，QPS=200，理论需要 40 个连接（200 × 0.2），但得预留缓冲，设成 60~80 更稳
- HikariCP 等现代池默认不设
minIdle，靠idleTimeout自动回收；若设，建议为maxActive的 10%~20%，避免低峰期空耗资源 - Java 应用里，
initialSize建议等于minIdle，避免启动后首次查询慢
超时和验证必须配对，否则会积压无效连接
光设了 maxActive 不配超时，连接池可能卡在等一个永远回不来的连接上；不验证，拿到的可能是数据库已断开的“僵尸连接”。
-
connectionTimeout（获取连接超时）：建议 3~30 秒，太短容易误抛异常，太长会让线程卡死。需与数据库的wait_timeout（默认 8 小时）错开，通常设为后者的 1/10~1/3 -
validationQuery或connectionTestQuery：用SELECT 1最轻量，HikariCP 推荐用isValid()（底层调mysql_ping()），比执行 SQL 更快 -
idleTimeout和maxLifetime要配合：前者控制空闲连接多久被回收（如 10 分钟），后者控制连接最大存活时间（如 30 分钟），防止连接因数据库主动断连而失效
最常被忽略的是监控联动——maxActive 设再合理，没看 Threads_connected、池的 active/idle 比、等待队列长度，就跟闭眼开车一样。上线后必须盯住这些指标，再反向调参。
