盲目调大 maximumPoolSize 或 max_connections 是导致 MySQL 崩溃最直接诱因，根源在于连接“假忙”：被事务卡住、未归还或服务端静默断开后仍被复用。
盲目调大 maximumPoolSize 或 max_connections 是导致 MySQL 崩溃最直接的诱因，不是连接不够用，而是连接在“假忙”——大量被事务卡住、没归还、或被服务端静默断开后仍被池子当作有效连接复用。
为什么 HikariCP 的 connectionTimeout 设 30 秒会拖垮线上服务
默认 connectionTimeout=30000 意味着业务线程会卡死 30 秒才抛异常，期间既不响应用户，也不释放资源。高并发下几十个线程同时挂起，CPU 和线程栈迅速吃紧。
- 线上必须显式设为
2000～5000（毫秒），让请求快速失败，由上游重试或降级兜底 - 这个值要略大于数据库平均响应时间（查
SHOW STATUS LIKE 'Threads_running'+ 慢查询日志估算），但绝不能容忍“等半分钟” - 若频繁触发超时，优先排查 SQL 是否慢、锁是否未释放，而不是调大该值
idleTimeout 和 MySQL 的 wait_timeout 必须错开
HikariCP 的 idleTimeout 如果 ≥ MySQL 的 wait_timeout，连接会被服务端主动断开，而池子还不知道——下次取出就报 Connection closed 或 Communications link failure。
- 先查 MySQL 当前设置：
SHOW VARIABLES LIKE 'wait_timeout';（常见默认是 28800，即 8 小时；但生产常缩至 300～600） - 对应设
idleTimeout为该值的 80%～90%，例如 MySQL 设了wait_timeout=300，HikariCP 就设idleTimeout=240000（4 分钟） - 同时配
validationTimeout=3000+connectionTestQuery="SELECT 1"，确保取连接前做轻量校验
maximumPoolSize 不是算出来的，是压测+监控挤出来的
公式 QPS × avg_response_time × buffer 只能当起点，真实瓶颈往往藏在事务边界、连接泄漏或读写分离路由里。
- MySQL 侧先看
SHOW STATUS LIKE 'Threads_running';—— 这才是真干活的线程数；长期 > 50 就说明 SQL 或锁有问题，不是池子小 - 应用侧监控 HikariCP 的
active、idle、pending三个指标：若active ≈ maximumPoolSize且pending > 0，大概率是连接没归还（比如@Transactional没 catchException、ResultSet没 close） - DBA 允许的
max_connections若为 500，单实例 HikariCP 最多设maximumPoolSize=350，留 150 给备份、监控、DBA 手动操作
minimumIdle = maximumPoolSize 是防抖关键
很多配置把 minimumIdle=0 或极小值，结果一有突发流量，所有连接都要重建，SSL 握手、TCP 建连、权限校验全来一遍，瞬间打满数据库 handshake 负载。
- 设
minimumIdle=maximumPoolSize（比如都为 20），启动即预热满池，消除冷启动毛刺 - 配合
keepaliveTime=200000（200 秒），让池子主动发心跳保活，避免 NAT 或 LB 中间件 silent kill 空闲连接 - 再加
leakDetectionThreshold=60000，一旦连接被借出 60 秒没归还，HikariCP 打 WARN 日志，帮你定位哪段代码忘了close()
真正容易翻车的点不在参数数字本身，而在“连接生命周期脱离掌控”——事务没结束、ResultSet 没关闭、异常吞掉 rollback、中间件悄悄断连。配再大的池子，只要连接不出池，就只是把崩溃延迟几秒而已。
