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()都有明确的、可验证的归还路径。
