MySQL连接池怎么配置？连接池大小如何设置，性能优化技巧

MySQL连接池配置的核心结论

MySQL连接池的配置并非越大越好，而是需要结合业务并发量、数据库性能、网络延迟和应用服务器资源综合权衡，最优配置绝不是套用固定模板，而是通过压测和监控持续调优的结果。连接池的核心价值在于复用数据库连接、降低连接创建销毁的开销，从而提升系统的吞吐能力和响应速度。

initialSize（初始连接数）：建议设置为 5-10，容器启动时预创建，避免流量高峰瞬间建连的延迟。
maxActive（最大活跃连接数）：这是最核心的参数，建议起步为 20-50，过小会导致请求排队，过大则可能压垮数据库，需要明确的是，每条连接都会占用数据库端的内存和线程资源。
maxIdle（最大空闲连接数）：建议与initialSize保持一致或略高，避免频繁回收和重建连接，现代连接池（如HikariCP）中该参数已弱化，由minIdle替代。
minIdle（最小空闲连接数）：建议设为 5-10，这是连接池的“安全网”，当请求量下降时，池内至少保留这些连接以应对突发流量。
maxWait（获取连接超时时间）：建议 3000-5000 毫秒，超过此时长则抛出异常，防止请求无限阻塞堆积，过短会误杀慢查询，过长会造成线程堆积，用户体验下降。

maxEvictableIdleTimeMillis：连接最大空闲时间，建议 600000 毫秒（10分钟），数据库服务端（如MySQL wait_timeout）通常默认关闭8小时空闲连接，客户端需提前主动回收，避免使用已被服务端断开的“僵尸连接”。
connectionTimeout（仅HikariCP）：与maxWait类似，建议 3000 毫秒。
idleTimeout（仅HikariCP）：默认 600000 毫秒（10分钟），HikariCP的核心设计理念是简洁且激进，该参数在maxPoolSize小于10时，会默认强制回收所有空闲连接。

许多开发者崇尚 连接数 = ((核心线程数 2) + 有效存储设备数) 等纯理论公式，但在实际生产环境中，我更推荐采用 反向压测法：

先定数据库能承受的极限，再反推连接池上限。 监控MySQL的 Threads_connected 指标，若在压测中发现活跃连接数始终低水位运行（如30%），说明连接池上限设置过高，纯属资源浪费；若连接等待超时频繁，则需逐步加并发连接数或优化SQL。

需要特别留意的是，大型连接池反而可能拖垮性能。 MySQL单实例在默认配置下，并发达300个连接时TPS性能会出现剧烈波动，因为数据库CPU被大量耗用在线程上下文切换，而非执行SQL，此时用Redis加上热数据缓存，将连接池压回100以内，性能反而提升近3倍。

场景：一套电商秒杀系统（使用酷番云云服务器 + 云数据库MySQL），大促前在压测阶段频繁报 Connection is not available, request timed out。

排查与调优步骤：

初步诊断：原配置为maxActive=100，maxWait=10000ms，连接池默认参数，监控面板显示数据库服务器CPU负载高达 90%，但应用端仍有大量请求超时，问题不在连接数不足，而是单条SQL执行过慢，将连接长时间占用。
执行SQL优化：联合索引缺失导致核心查询扫描行数达百万级，添加索引后查询耗时从 2.1s 降至 80ms。
重新调整连接池：将maxActive由100降至 50，maxWait由10000ms缩短至 3000ms，并开启testWhileIdle与SELECT 1心跳。此时数据库CPU负载降至 30%，连接池等待率降为0，整体吞吐量反而提升了 15%。

核心结论复盘：连接池调优不是单纯修改参数，首先要排除SQL耗时过长、慢查询导致的连接长期占用，酷番云的云监控服务在识别慢SQL与数据库负载关联分析中，起到了快速定位的关键作用，缩短了排查链路。