MySQL连接池是应用层实现的连接复用机制，通过缓存Connection对象避免重复建连开销；配置需匹配MySQL承载力、并发模型与查询耗时，HikariCP等应设maximumPoolSize≤max_connections×0.8，并防范连接泄漏。
MySQL 连接池不是 MySQL 自己提供的功能，而是应用层（比如 Java、Python、Node.js）用第三方库实现的「连接复用机制」：它提前建好一批 Connection 对象，缓存在内存里，每次业务需要查库时，直接从池子里“借”一个，用完再“还”回去——不关掉，也不重建。
这能省下 TCP 握手、身份认证、权限校验等开销，把单次连接建立从 50–200ms 缩短到微秒级。没连池？高峰期每秒 100 次请求，可能就在反复创建/销毁连接上卡死。
为什么连池配置错，比 SQL 慢更致命
很多团队花大力气优化 SELECT，却让连接池最大值设成 100，而 MySQL 的 max_connections 实际只有 151。结果是：
- 应用侧大量线程卡在
getConnection()上，等待超时抛Unable to acquire JDBC Connection - 数据库端
Threads_connected接近上限，新连接被拒绝，错误日志刷屏Too many connections - 监控上看 QPS 没涨，但平均响应时间飙升——其实是排队等连接，不是数据库慢
根本原因：连接池不是“越大越好”，而是要和 MySQL 承载力、应用并发模型、单次查询耗时三者对齐。
HikariCP / Druid 关键参数怎么设才不翻车
以主流 Java 连接池 HikariCP 为例（Python 的 SQLAlchemy、Node.js 的 Knex 原理类似，只是参数名不同）：
maximumPoolSize：必须 ≤ MySQL 的max_connections × 0.8
比如 MySQL 配了max_connections=200，这里最多设160；再按业务估算：峰值 QPS=200，平均查询耗时 40ms → 理论需 200 × 0.04 = 8 个活跃连接，留 2× 缓冲也只需16～20。宁小勿大。minimumIdle和initializationFailTimeout：建议设为maximumPoolSize × 0.2
避免冷启动时第一个请求触发连接创建延迟；但别设成和最大值一样，否则空闲连接长期占着资源却不干活。connection-timeout（即connectionTimeout）：3000–5000ms
网络抖动时，别让一个连接卡住整个线程池。validationQuery必须配SELECT 1，且开启testOnBorrow或testWhileIdle
否则 MySQL 因wait_timeout主动断开后，池子里的“死连接”还在，一借就报Communications link failure。
spring:
datasource:
hikari:
maximum-pool-size: 20
minimum-idle: 4
connection-timeout: 4000
validation-timeout: 3000
idle-timeout: 600000
max-lifetime: 1800000
connection-test-query: SELECT 1
test-on-borrow: true最容易被忽略的三个泄漏点
连接没归还、事务没结束、异步逻辑没兜底——这三类问题不会立刻报错，但会缓慢吃光连接池：
try-with-resources漏写或用了finally却没调conn.close()
→ HikariCP 的leakDetectionThreshold（单位 ms）可抓到，建议设60000（60 秒），超时未归还会打 WARN 日志。Spring @Transactional 方法内起新线程执行 DB 操作
→ 新线程拿不到事务上下文，也拿不到当前线程绑定的连接，容易自己 new Connection 又不关。使用 CompletableFuture 异步查库，但没在
whenComplete或handle里确保连接释放
→ 异步回调可能失败或跳过，连接就永远滞留在池外。
真正稳的连池，不靠参数堆得多，而靠每一次 getConnection() 都有明确的、可验证的归还路径。
