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、一个没关的连接、一个过大的池配置，就可能压垮系统。关键在持续监控 + 快速定位 + 精准收敛。
