连接池限流是控制MySQL并发访问最直接有效的方式，核心是通过设置最大活跃连接数（如HikariCP的maximum-pool-size=20）防止连接耗尽；需结合压测结果合理配置，并辅以超时、泄漏检测、空闲回收等策略，配合MySQL层锁优化与资源组隔离，再通过监控指标动态调优。
使用连接池限流是控制 MySQL 并发访问最直接有效的方式，核心在于不让过多请求挤占数据库连接资源，避免连接耗尽、响应延迟甚至服务雪崩。
设置连接池最大活跃连接数
这是限流最关键的配置。应用启动时，连接池会预建一定数量的连接（初始连接数），但真正起限流作用的是最大活跃连接数（maxActive / maxPoolSize）。一旦达到该值，后续获取连接的请求会被阻塞或快速失败。
- Spring Boot + HikariCP 示例：在 application.yml 中设置 spring.datasource.hikari.maximum-pool-size=20，表示最多同时使用 20 个连接
- 要结合业务压测结果调整：比如单次查询平均耗时 100ms，系统每秒峰值请求 100 QPS，则理论最小连接需求 ≈ 100 × 0.1 = 10；建议留 1.5–2 倍余量，设为 15–20 较稳妥
- 切忌盲目调大：MySQL 默认 max_connections 通常为 151，若多个服务或实例共用同一库，总连接数超限会触发 “Too many connections” 错误
配置等待与超时策略防死锁
光设上限不够，还要管“等不及怎么办”，否则线程堆积会拖垮整个应用。
- 设置连接获取超时时间（connection-timeout）：HikariCP 默认 30 秒，建议缩至 3–5 秒，超时后抛异常而非无限等待
- 开启连接泄漏检测（leak-detection-threshold）：如设为 60000（毫秒），若连接被借出超 60 秒未归还，日志报警，帮助定位慢 SQL 或未关闭连接的代码
- 启用连接空闲回收（idle-timeout）和最大生命周期（max-lifetime），避免长连接因网络抖动或 MySQL wait_timeout 主动断开导致的 InvalidConnection 问题
配合数据库层做协同限流
连接池是应用侧第一道闸门，MySQL 本身也能辅助控制并发粒度。
- 对高频写入接口，可在 SQL 层加 SELECT ... FOR UPDATE SKIP LOCKED 避免行锁争抢；读多写少场景优先用 READ COMMITTED 隔离级别降低锁范围
- 利用 MySQL 8.0+ 的 RESOURCE GROUP 绑定线程池资源，限制某类查询最多占用 CPU 时间或并发线程数
- 对报表类慢查询，单独配置低优先级连接池（如最大连接数 5、超时 30 秒），与核心交易池物理隔离，避免相互影响
监控与动态调优不能少
限流配置不是一劳永逸，需靠数据驱动迭代。
- 重点关注连接池指标：HikariCP 提供 active（当前活跃）、idle（空闲）、waiting（等待线程数）——若 waiting 长期 > 0，说明连接数已成瓶颈
- 接入 Prometheus + Grafana，配置告警：当 active / maximum-pool-size 持续 > 90% 超 2 分钟，触发预警
- 灰度发布时，可基于 Spring Cloud Config 或 Nacos 动态推送 new maximum-pool-size，实现不停机调参
