MySQL高并发连接耗尽本质是请求速度超服务处理能力，致连接池占满、新请求被拒；应控入口（合理设max_connections）、提效率（优化查询与索引）、稳释放（规范连接池管理与超时清理）。
MySQL高并发下连接耗尽，本质是客户端请求速度远超服务端处理能力，导致连接池被占满、新请求被拒绝（报错 Too many connections）。核心思路不是盲目加连接数，而是“控入口、提效率、稳释放”。
合理设置最大连接数（max_connections）
盲目调高 max_connections 会加剧内存压力（每个连接约占用 256KB–1MB 内存），甚至引发 OOM。应结合实际负载评估：
- 查看当前峰值连接数：
SHOW STATUS LIKE 'Threads_connected';或监控历史趋势 - 预留 20%–30% 余量，例如业务峰值稳定在 800，则设为 1000–1100
- 修改后需重启或动态生效：
SET GLOBAL max_connections = 1000;（注意该值重启失效，需写入配置文件my.cnf的[mysqld]段）
优化应用层连接管理
多数连接耗尽源于应用未正确复用或释放连接：
- 必须使用连接池（如 HikariCP、Druid、DBCP2），禁用直连或每次请求新建连接
- 设置合理的池参数：最小空闲（
minimumIdle）、最大活跃（maximumPoolSize）、连接超时（connectionTimeout）、空闲连接存活时间（idleTimeout） - 确保
try-with-resources或显式调用close()，避免连接泄露；可开启 Druid 的removeAbandonedOnBorrow=true自动回收疑似泄漏连接
缩短单次查询与连接占用时间
慢查询会长期持有连接，形成阻塞链。重点排查：
- 开启慢查询日志：
slow_query_log = ON，long_query_time = 1，定期分析mysqldumpslow或 pt-query-digest - 为高频查询添加合适索引，避免全表扫描；用
EXPLAIN验证执行计划 - 拆分大事务，减少锁持有时间；避免在事务中做 HTTP 调用、文件读写等外部耗时操作
- 读多写少场景可引入读写分离，将查询流量分摊到从库，减轻主库连接压力
主动清理无效/僵死连接
网络异常、应用崩溃会导致连接未正常关闭，堆积为“僵尸连接”：
- 设置
wait_timeout和interactive_timeout（单位秒），建议 60–300，让空闲连接自动断开 - 应用侧启用连接池的“测试连接有效性”机制（如 HikariCP 的
connectionTestQuery=SELECT 1+validationTimeout） - 必要时手动 Kill 异常连接：
KILL [ID];，或通过脚本定期清理状态为Sleep且时间过长的连接
不复杂但容易忽略：连接耗尽往往是多个小问题叠加的结果——一个慢 SQL、一个没关的连接、一个过大的池配置，就可能压垮系统。关键在持续监控 + 快速定位 + 精准收敛。
