MySQL连接池连不上或频繁超时主因是配置与应用行为不匹配，如maximumPoolSize超MySQL max_connections、idleTimeout未小于wait_timeout导致连接失效，需协同调优连接池与MySQL参数并监控复用率。
MySQL连接池为什么连不上或频繁超时
绝大多数连接池问题不是数据库本身扛不住，而是配置和应用行为不匹配。比如 maxActive 设太高，但 MySQL 的 max_connections 没同步调大，结果新连接直接被拒绝，报错 Too many connections；或者 minIdle 设为 0，每次请求都得新建连接，响应延迟明显升高。
- 先查 MySQL 实际允许多少连接：
SHOW VARIABLES LIKE 'max_connections';
- 连接池最大值（如 HikariCP 的
maximumPoolSize）建议设为 MySQL 值的 70%～80%，留余量给管理连接、备份等后台操作 - 避免把
initializationFailTimeout设成负数或过大——它决定启动时是否等待池初始化完成，设太大会拖慢应用启动
HikariCP 连接池关键参数怎么配才不翻车
HikariCP 是目前 Java 生态最常用的 MySQL 连接池，但默认配置偏保守，上线前必须调整。尤其要注意它没有 maxActive 这种老式命名，对应的是 maximumPoolSize，别套用 DBCP 的习惯去配。
-
connectionTimeout：建议 3000（3秒），太短容易误判网络抖动，太长会让上层接口卡住 -
idleTimeout：设 600000（10分钟），比 MySQL 的wait_timeout小至少 2 分钟，否则连接会被 MySQL 主动断开，池里还留着失效连接 -
maxLifetime：设 1800000（30分钟），强制刷新长期存活连接，避开 MySQL 的连接老化、事务状态残留等问题 - 务必开启
leakDetectionThreshold（比如 60000），能抓到 Connection 没 close 的代码，这是线上连接耗尽最常见的原因
MySQL 侧要同步调哪些参数
只调连接池不碰 MySQL 配置，等于单边优化。重点不是“让 MySQL 支持更多连接”，而是让每个连接更轻、更可控。
-
wait_timeout和interactive_timeout建议统一设为 600（10分钟），和连接池的idleTimeout形成配合 -
max_connect_errors别锁死在默认 10，测试环境可设高些，避免因连接池探活失败触发 host blocked - 如果应用大量短连接，开启
skip_name_resolve，省掉 DNS 反查开销，实测可降 5～10ms/连接建立 - 确认
innodb_buffer_pool_size已占物理内存 50%～75%，否则连接再多也卡在磁盘 IO 上
怎么验证连接池真的调好了
别只看“没报错”或“QPS 上去了”。真正稳的连接池，应该在压测中表现出低且稳定的连接复用率、极少的连接重建、以及 active 数始终贴近 idle 数波动。
- 用 HikariCP 的 JMX 或
HikariDataSource.getHikariPoolMXBean()实时查getActiveConnections、getIdleConnections、getThreadsAwaitingConnection - 抓一次慢日志，过滤出
Connect类型事件，看平均建连时间是否 - 监控
Aborted_connects状态变量，突增说明连接池配置和 MySQL 不兼容（比如 SSL 要求不一致、用户权限不足）
连接池调优不是改几个数字就完事，它横跨应用、驱动、中间件、MySQL 四层，任何一层的 timeout、buffer、认证策略不一致，都会导致连接半途失效。最容易被忽略的是 MySQL 的 wait_timeout 和连接池 idleTimeout 的差值——差得太小，连接总在“刚要用时被 MySQL 断掉”；差得太大，又可能积累大量僵死连接。
