MySQL数据库连接数过多怎么排查_使用max_connections参数优化

张开发
• 2026/4/7 1:28:40 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

MySQL数据库连接数过多怎么排查_使用max_connections参数优化
先查 SHOW STATUS LIKE Threads_connected 和 SHOW PROCESSLIST 确认是否真超限重点排查未关闭的 Sleep 连接再检查 ulimit 和连接池配置确保应用层正确释放连接。怎么确认当前连接数真的超了MySQL 报错 Too many connections 时别急着调大 max_connections。先看真实连接状态用 SHOW STATUS LIKE Threads_connected; 查当前活跃连接数再用 SHOW PROCESSLIST; 看具体是谁占着不放——尤其是大量 Sleep 状态的连接大概率是应用没正确关闭连接。应用层未调用 connection.close() 或未走连接池回收逻辑是最常见原因 某些 ORM如 Django 默认配置在长连接场景下会复用连接但不主动释放导致空闲连接堆积 wait_timeout 和 interactive_timeout 值设得过大比如 28800 秒会让 Sleep 连接挂太久 查完发现 Threads_connected 接近或等于 max_connections才说明真瓶颈在这儿。max_connections 改多少才算合理max_connections 不是越大越好。它直接影响 MySQL 的内存占用每个连接约 256KB~1MB 内存开销设太高可能触发 OOM 或拖慢响应。先估算单个应用实例平均并发连接数 × 实例数 × 1.5留余量比如 4 台应用各撑 100 并发建议从 600 起步 生产环境不建议直接设到 2000除非你确认 buffer pool、sort_buffer_size 等配套参数已调优 修改方式有两种SET GLOBAL max_connections 1000;重启失效或改配置文件 my.cnf 中的 max_connections 1000 后重启 mysqld 注意动态 SET 需要有 SYSTEM_VARIABLES_ADMIN 权限MySQL 8.0 才支持部分变量热改。为什么调了 max_connections 还是连不上改完参数仍报 Too many connections大概率是被操作系统级限制卡住了。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。

更多文章