连接池配置需匹配数据库max_connections上限，HikariCP须配齐maximum_pool_size、minimum_idle和connection-timeout，配合健康检查与实时监控active/idle/threads_waiting指标才能保障稳定。
连接池不是“开得越多越好”，而是要匹配数据库承受力
直接结论：max_connections 是 MySQL 服务端的硬性上限，应用层连接池再大也跨不过去。如果应用配置了 maximum_pool_size=100，但 MySQL 的 max_connections=50，那超过 50 个并发请求就会触发 Error 1040 (08004): Too many connections。这不是应用代码写错了，是服务端拦下来的。
所以第一步永远是查清数据库实际允许多少连接：
- 执行
SHOW VARIABLES LIKE 'max_connections';看当前值（默认通常是 151） - 用
SHOW STATUS LIKE 'Threads_connected';观察真实活跃连接数 - 检查是否有长期空闲连接没归还——这类连接占着名额却不干活，会把池子“堵死”
HikariCP 的三个关键参数必须配齐，缺一不可
Java 项目里用 HikariCP，只设 maximum_pool_size 是常见误区。它和 minimum_idle、connection-timeout 是联动关系，漏掉任何一个都可能在高并发下出问题。
典型错误现象：接口偶发超时，日志里出现 Connection acquisition timed out —— 这说明连接池等不到可用连接，不是数据库慢，是池子没管好。
-
maximum_pool_size：建议设为 MySQLmax_connections的 60%~80%，留出空间给 DBA 工具、监控脚本等非业务连接 -
minimum_idle：设成和maximum_pool_size一致（比如都为 20），能避免冷启动时首次请求延迟高 -
connection-timeout：别用默认 30 秒，设成 5~10 秒更合理；超时后应快速失败，而不是让线程卡住
连接“看着在池里”，其实早被 MySQL 主动断开了
MySQL 默认会在空闲 8 小时（wait_timeout=28800）后关闭连接。如果连接池里的空闲连接没做健康检查，下次取出时就会报 Communications link failure 或 Connection reset。
这不是连接池 bug，是网络中间件或数据库主动清理导致的。解决方式不是调大 wait_timeout，而是让连接池自己处理：
- HikariCP 加
connection-test-query=SELECT 1（MySQL 8.0.22+ 推荐用isValid()） - SQLAlchemy 加
pool_pre_ping=True，每次取连接前先 ping 一下 - Go 的
db.SetConnMaxLifetime(time.Hour)强制每小时重建连接，比依赖 MySQL 超时更可控
监控比调参更重要，但很多人连基础指标都没看
连接池配置再合理，没监控就等于蒙眼开车。真正该盯的不是“最大连接数设了多少”，而是这几个实时指标：
-
active：当前正在被业务使用的连接数 —— 持续接近maximum_pool_size，说明池子真不够用了 -
idle：空闲连接数 —— 长期为 0，大概率是连接没归还（比如忘了close()或没进try-with-resources） -
threads_waiting（HikariCP）：等待连接的线程数 —— 大于 0 就说明有请求在排队，响应延迟必然上升
这些指标 HikariCP 通过 JMX 或 HikariDataSource.getMetrics() 能拿到，SQLAlchemy 可用 engine.pool.checkedout 查活跃数。不看它们，光改配置只是碰运气。
