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 断掉”；差得太大，又可能积累大量僵死连接。
