mysql最大连接数默认为151，需综合max_connections、操作系统文件描述符限制及内存容量三层限制；实际安全上限应扣除复制线程、运维连接并预留10%～20%余量。
最大连接数不能只看并发QPS，得算MySQL实际扛得住几个
直接设 maximumPoolSize=100 很危险——它可能远超 MySQL 实际允许的连接上限。先查清楚服务端底限：SHOW VARIABLES LIKE 'max_connections';。默认是 151，很多生产库也没调高。如果应用有 3 个实例，每个池设 50，总连接就到 150，再加一个监控或备份连接，立刻触发 error 1040 (08004): Too many connections。
真正安全的上限是：max_connections 减去保留连接（通常 1～2 个）、复制线程、后台运维连接后剩余的值。建议留出 10%～20% 余量，比如 max_connections=200，则所有实例连接池总和控制在 160 以内。
- 别信“CPU核数×4”这种泛泛而谈的公式，它没考虑单连接内存开销（每个连接约占用 256KB～1MB 内存）
- 用
SHOW STATUS LIKE 'Threads_connected';持续观察真实占用，比预估更可靠 - 如果
Max_used_connections长期 > 90% 的max_connections，优先优化慢查询或连接泄漏，而不是盲目调大池子
最小空闲连接不是“越多越好”，而是防抖动的缓冲带
minimumIdle 的作用不是加速冷启动，而是应对突发流量时避免频繁创建新连接。设太高会提前占满连接池额度，反而让后续请求排队；设太低（比如 0 或 1），流量一抖就触发新建连接，放大 TCP 握手和认证开销。
合理值通常是 maximumPoolSize 的 10%～25%，且不低于 5。例如最大设 30，最小空闲可设 6～8。但注意：HikariCP 默认启用 minimumIdle 自适应（当 minimumIdle 时才生效），若设为 0，则空闲连接会逐步归零，突发来临时全靠新建——这在高延迟网络下极易超时。
- Spring Boot 用户注意：
spring.datasource.hikari.minimum-idle必须显式配置，否则默认为 0（HikariCP 5.0+） - Druid 中对应参数是
minIdle，行为类似，但默认值为 0，同样需手动设 - 如果应用部署在容器中且启用了水平扩缩，
minimumIdle应按单实例预估，不能按集群总量设
连接池大小和数据库响应时间强耦合，50ms 延迟意味着 20 连接只是理论下限
常见错误是把“每秒处理 400 请求”直接乘以平均耗时 50ms，得出需要 20 连接——这忽略了连接复用率、事务嵌套、批量操作等现实干扰。真实场景中，一个连接可能串行处理多个语句，也可能被长事务独占数秒。
更稳妥的估算方式是：取 P95 响应时间 × 并发请求数 × 1.2～1.5 安全系数。例如压测发现 P95 是 80ms，峰值并发 300，那基础池大小至少是 300 × 0.08 × 1.3 ≈ 31，再向上取整到 35～40。
- 如果数据库存在慢查询（>1s），单个连接被长时间占用，会导致其他请求卡在
connectionTimeout上，此时调大池子只是掩盖问题 - 用
SELECT COUNT(*) FROM information_schema.processlist WHERE Command != 'Sleep';查活跃非空闲连接，若长期 > 80% 的maximumPoolSize，说明连接正在被阻塞而非等待 - 连接池监控里重点关注
activeConnections和idleConnections的比值，持续接近 1 表示池子已绷紧，该查业务了
HikariCP 的 maximumPoolSize 和 minimumIdle 不是独立参数，它们共同决定连接生命周期压力
很多人单独调大 maximumPoolSize 却忽略 idleTimeout 和 maxLifetime，结果出现连接老化、MySQL 主动断连、应用报 Connection is closed。这三个参数必须协同设置：
maxLifetime 应比 MySQL 的 wait_timeout（默认 28800 秒）小至少 300 秒，推荐 1800000（30 分钟）；idleTimeout 要小于 maxLifetime，推荐 600000（10 分钟）；而 minimumIdle 如果设得过高（比如等于 maximumPoolSize），会导致大量连接长期存活却无事可做，白白消耗资源并增加失效风险。
- 一旦
minimumIdle == maximumPoolSize，池子变成“静态池”，所有连接都会活满maxLifetime，故障率上升 - HikariCP 在
minimumIdle低于maximumPoolSize时，会主动驱逐空闲超时连接，这是健康回收的关键机制 - 如果你的应用部署在云环境且 MySQL 后端有 LB 或代理（如 ProxySQL、Cloud SQL Auth Proxy），
idleTimeout必须进一步缩短（建议 ≤ 300000），否则中间件可能先于 MySQL 断连
