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] 段）

优化应用层连接管理

多数连接耗尽源于应用未正确复用或释放连接：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

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