MySQL连接池配置在应用层而非服务端，需通过Threads_connected波动、日志监听及pool.getConnection()/release()显式调用验证是否生效，避免连接泄漏与超限卡死。
MySQL安装后，连接池配置本身不会自动生效——它只存在于应用代码或中间件中，数据库服务端根本不知道你在用连接池。验证的重点不是“MySQL有没有配好连接池”，而是“你的应用是否正确创建、复用并释放了连接池中的连接”。
连接池配置不在MySQL服务端，而在客户端代码里
MySQL服务本身没有“连接池”这个配置项。max_connections是服务端能接受的最大并发连接数，但它和应用层的连接池（比如mysql.createPool()）是两回事。你改了my.cnf里的max_connections = 500，只是给连接池留出了空间；真正决定是否启用池、池大小多少、超时多久的，是你的Node.js、Java或Python代码。
-
mysql.createConnection()每次新建物理连接，不复用，不适合高并发 -
mysql.createPool()才启用连接复用，必须显式调用pool.getConnection()和connection.release() - 漏掉
release()或没处理error事件，会导致连接泄漏，Threads_connected持续上涨
怎么确认连接池真正在工作？看 Threads_connected + 日志
登录MySQL执行：SHOW STATUS LIKE 'Threads_connected';，再反复触发应用的数据库操作（比如刷新网页、调用API），观察这个值的变化幅度：
- 如果始终在2–5之间小幅波动（哪怕并发请求有20个），说明连接被复用了，池在起作用
- 如果每次请求都+1，且不回落，大概率没调用
connection.release()，或者池配置了acquireTimeout但没设waitForConnections: true - 配合
SHOW PROCESSLIST;看当前活跃连接的User和Host，确认是不是你的应用IP在反复建连
Node.js里最容易踩的坑：pool.query()看似方便，实则绕过连接管理
pool.query()会自动获取、执行、释放连接，看起来省事，但隐藏了控制权。一旦SQL出错或超时，你很难知道连接是否真的被归还。
- 推荐显式流程：
pool.getConnection()→connection.query()→connection.release()→connection.destroy()（仅出错时） - 务必监听
pool.on('acquire', ...)和pool.on('release', ...)，打日志验证生命周期 - 别把
pool当全局单例乱传，尤其在Express中间件里，避免意外共享或覆盖配置
连接池参数不匹配 MySQL 的 max_connections 就会卡死
比如MySQL配置了max_connections = 100，而你的Node.js应用启了3个实例，每个配了connectionLimit: 50，合计150——超过上限后新请求就会卡在waitForConnections: true，直到超时抛PoolTimeoutError。
- 查MySQL实际限制：
SHOW VARIABLES LIKE 'max_connections'; - 算总池上限：应用实例数 × 单实例
connectionLimit - 留20%余量，例如MySQL设200，应用总池数建议≤160
- 注意
wait_timeout（MySQL默认8小时）和acquireTimeout（Node池默认10秒）的协同，避免连接被服务端主动断开却未被池感知
连接池不是开个配置就完事的东西，它依赖代码逻辑、服务端参数、应用部署规模三者对齐。最常被忽略的是：没监控Threads_connected趋势，也没在应用日志里埋点验证acquire/release是否成对出现。
