连接池最大连接数必须小于数据库max_connections并预留至少20%余量，否则易触发Too many connections错误；推荐所有实例maximumPoolSize总和≤max_connections×0.7，且需结合CPU核心数（如8核设16～32）、Threads_running监控及泄漏排查综合调优。
连接池最大连接数不能直接设为 max_connections
应用侧连接池（如 HikariCP 的 maximumPoolSize、Go 的 SetMaxOpenConns）必须小于数据库端的 max_connections，且要留出至少 20% 余量。否则会出现 Too many connections 错误，而此时 MySQL 的 CPU 和内存可能还很空闲。
原因在于：DBA 工具、备份脚本、监控采集、慢查日志轮转等后台任务都会占用连接；另外云数据库（如阿里云 RDS、PolarDB）还会预留一部分连接用于内部管理。
- 先执行
SHOW VARIABLES LIKE 'max_connections';查当前上限（常见值为 151 或 1000） - 再执行
SHOW STATUS LIKE 'Threads_connected';观察 15 分钟以上峰值，不是瞬时值 - 若你有 3 台应用实例，每台池子设 30，则总理论连接数是 90 —— 这对默认 151 的本地 MySQL 已非常接近临界点
- 更稳妥的公式是：
所有实例的 maximumPoolSize 总和 ≤ max_connections × 0.7，比如 RDS 返回 1000，那加起来别超 600
thread_pool_size 在社区版 MySQL 中根本不可用
很多教程说“调大 thread_pool_size 可减少上下文切换”，但这是个典型误区：MySQL 社区版（5.7/8.0）原生不支持线程池插件，执行 INSTALL PLUGIN thread_pool SONAME 'thread_pool.so'; 会报错 Unknown plugin 'thread_pool'。
真正可用的替代方案是调整 thread_cache_size —— 它缓存空闲线程供新连接复用，避免频繁创建销毁线程带来的开销：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
thread_cache_size推荐设为ceil(max_connections / 16)，但一般不超过 16 - 设太高反而增加线程管理开销，观察
Threads_created是否持续上升：如果上升快，说明缓存不够；如果长期为 0，说明已足够 - 该参数只在连接反复建立/断开的场景下有效（如短连接多、连接池配置不合理），长连接为主的应用影响很小
连接池大小设多少，取决于 CPU 核心数而非并发请求数
盲目按 QPS 或用户数估算连接池大小，容易导致资源浪费或瓶颈前移。连接池本质是协调应用线程与数据库线程之间的映射关系，关键约束是服务端的 CPU 并发处理能力。
- 推荐起点：连接池最大值 = 应用服务器 CPU 核心数 × 2～4，例如 8 核机器设为 16～32
- 高 I/O 密集型（如 Dify 类应用）可偏向高值；计算密集型或 SQL 复杂度高（排序/JOIN 多）则应保守些
- 务必配套监控
Threads_running（正在执行的线程数）：若它长期接近maximumPoolSize，说明不是连接不够，而是 SQL 慢或锁等待，调大池子只会加重排队 - 云环境特别注意：PolarDB、CynosDB 等对单连接内存更敏感，
maximumPoolSize=50在 4 核机器上就可能触发主动 Kill
连接泄漏比连接数不足更危险，且更难被发现
很多 “连不上” 报错不是因为 max_connections 小，而是连接没归还。这类泄漏不会立刻爆发，而是让 Threads_connected 缓慢爬升，几天后突然卡死。
- 检查方法：执行
SHOW PROCESSLIST;，重点关注大量Sleep状态且Time值持续增长的连接 - 代码层面必须确保每个
db.Query/session.execute都配对defer rows.Close()或session.close()，异常路径也不能漏 - 连接池框架（如 HikariCP）开启
leakDetectionThreshold（如 60000ms），能主动打印泄漏堆栈 - 一旦确认泄漏，优先修复代码，而不是调大
max_connections或连接池 —— 后者只是掩盖问题
连接池大小和线程调度之间没有银弹式对应关系，最易被忽略的是：连接数打满往往不是性能瓶颈的起点，而是其他问题（SQL 慢、锁争用、连接泄漏）已经持续恶化后的结果。
