database Troubleshooting
MySQL Too many connections 排查与缓解
MySQL 报 Too many connections、连接数达到 max_connections 时，SHOW PROCESSLIST 按用户/IP/数据库/状态聚合连接，识别大量 Sleep 或长时间 Sending data 的会话，检查应用连接池 max pool size 是否超过数据库承载，而不是盲目调大 max_connections。
先看当前连接来自哪些用户和主机，再判断是突发流量、慢查询阻塞还是连接池配置过大。不要只调大 max_connections 掩盖问题。
Scenario
这篇文章解决什么问题
适用于“MySQL Too many connections 排查与缓解”对应的线上或本地排障场景。不要只根据最终报错下结论，应先把问题拆成入口、链路、目标服务和资源限制几层，再用命令逐层证实。先看当前连接来自哪些用户和主机，再判断是突发流量、慢查询阻塞还是连接池配置过大。不要只调大 max_connections 掩盖问题。
Symptoms
典型现象
- MySQL 报 Too many connections、连接数达到 max_connections 时，SHOW PROCESSLIST 按用户/IP/数据库/状态聚合连接，识别大量 Sleep 或长时间 Sending data 的会话，检查应用连接池 max pool size 是否超过数据库承载，而不是盲目调大 max_connections。
- 相关日志、命令或页面中反复出现 mysql、database、connections 等关键词。
- 同一服务在不同机器、不同入口或不同时间段表现不一致，需要通过证据链缩小范围。
Before Debugging
排查前先确认
- 先区分连接、认证、锁、慢查询、连接池、内存或持久化问题。
- 记录数据库端时间、应用实例数、连接池大小和报错 SQL。
- 任何 kill/调参前先确认是否影响正在执行的业务事务。
Root Causes
常见根因分层
连接池与数据库容量失配
实例数乘以每个实例连接池上限，可能远超数据库 max_connections；连接泄漏和慢查询会进一步放大问题。
- 统计来源用户和主机
- 查看 Sleep 与活跃连接比例
- 核对应用连接池配置
事务、锁和慢查询堆积
锁等待、长事务、缺索引更新和慢 SQL 会拖住连接，最终表现成连接数耗尽或接口超时。
- 查 processlist / innodb_trx
- 看 deadlock 和 lock waits
- 定位 blocking session
缓存或内存策略失控
Redis 大 key、无 TTL、noeviction、MySQL buffer/临时表配置都可能让系统进入持续抖动。
- 先看内存水位和策略
- 找大 key/慢查询
- 评估数据模型是否合理
Diagnosis Path
分步诊断流程
1. 固定现场，避免追着变化状态跑
先记录故障时间、影响入口、完整错误和最近一次变更。MySQL Too many connections 排查与缓解 这类问题经常在重启、重试或缓存刷新后短暂消失，没有现场信息会很难复盘。
- 截图或保存完整错误文本
- 记录请求域名/IP/端口/namespace/服务名
- 标出最近发布、配置、证书、镜像或依赖变更
mysql -e "SHOW PROCESSLIST"
mysql -e "SHOW STATUS LIKE 'Threads_connected'"2. 在故障发生的同一位置复现
很多误判来自测试位置不同：本机通不代表服务器通，容器内通不代表宿主机通，集群外通也不代表 Pod 内通。复现命令要尽量贴近真实流量路径。
- 从报错服务所在机器执行测试
- 必要时加 Host、SNI、namespace 或代理参数
- 把成功路径和失败路径的输出并排比较
mysql -e "SHOW STATUS LIKE 'Threads_connected'"
mysql -e "SHOW VARIABLES LIKE 'max_connections'"
mysqladmin processlist3. 读取服务端证据，而不是只看客户端提示
客户端报错通常是结果摘要。真正能区分根因的是服务端日志、内核日志、事件、进程状态或数据库状态。
- 确认 Threads_connected 与 max_connections 的比例。
- 按用户、来源 IP、数据库和状态聚合连接。
- 检查是否大量 Sleep 连接或长时间 Sending data/Locked。
mysql -e "SHOW VARIABLES LIKE 'max_connections'"
mysqladmin processlist
pt-kill --print --busy-time 604. 做最小修复并立即回归验证
每次只改一个变量，修复后用同一条复现命令回测，并观察日志是否停止增长。这样可以避免多个临时改动互相掩盖。
- 检查是否大量 Sleep 连接或长时间 Sending data/Locked。
- 查看应用连接池 max pool size 是否乘以实例数后超过数据库承载。
- 短期可 kill 明确异常连接，长期要修慢查询、连接泄漏或池配置。
mysqladmin processlist
pt-kill --print --busy-time 60Commands
排查命令与使用意图
命令 1
用于读取数据库当前连接、事务、锁或配置状态。执行前确认账号权限，涉及 KILL 的命令必须先判断事务影响。
mysql -e "SHOW PROCESSLIST"命令 2
用于读取数据库当前连接、事务、锁或配置状态。执行前确认账号权限，涉及 KILL 的命令必须先判断事务影响。
mysql -e "SHOW STATUS LIKE 'Threads_connected'"命令 3
用于读取数据库当前连接、事务、锁或配置状态。执行前确认账号权限，涉及 KILL 的命令必须先判断事务影响。
mysql -e "SHOW VARIABLES LIKE 'max_connections'"命令 4
用于读取数据库当前连接、事务、锁或配置状态。执行前确认账号权限，涉及 KILL 的命令必须先判断事务影响。
mysqladmin processlist命令 5
用于补充“MySQL Too many connections 排查与缓解”的排查证据链。pt-kill 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
pt-kill --print --busy-time 60Risk Notes
容易踩坑的地方
- 不要只调大 max_connections 掩盖连接泄漏或慢查询，这会让问题在更大规模上爆发。
- 不要在不了解用途时 FLUSHALL、DROP 或重启数据库，先确认这些操作对各业务的影响。
- 不要在生产环境直接执行未在测试环境验证过的 DDL 或 DML 操作。
Verification
修复后怎么确认
- 原始故障现象已经消失，且使用同一入口重新测试 MySQL Too many connections 能稳定成功。
- 服务端日志不再出现同类错误，监控中的错误率、重启次数、连接数或延迟回到正常区间。
- 如果做过临时绕过，已经记录恢复计划，例如还原宽松策略、补监控、补限制或提交正式配置。
Prevention
后续预防
- 为连接数、慢查询、锁等待和内存使用建立趋势监控，在问题发生前发现异常趋势。
- 把连接池大小按实例总数统一规划，而不是每个服务单独拍脑袋，避免 max_connections 被耗尽。
- 对批量更新、迁移脚本和缓存写入设置限速与回滚方案，防止误操作导致大范围故障。
- 定期审查慢查询日志和索引使用情况，主动优化而非被动应对。
常见问题
直接把 max_connections 调很大可以吗？
只能作为短期缓解。连接越多内存和调度开销越高，根因通常在应用连接池、慢查询或连接泄漏。
Sleep 连接都是坏的吗？
不一定，连接池会保留空闲连接。但大量长期 Sleep 且超过业务预期时，需要检查池大小和释放逻辑。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- MySQL Too many connections
- MySQL 连接数满 排查
- Threads_connected max_connections
- SHOW PROCESSLIST Sleep 很多
- MySQL 连接池配置过大
- MySQL max_connections 调整
- MySQL 慢查询导致连接堆积
- Host is blocked because of many connection errors
Need More Help
这个问题还没完全解决？
把你的报错、环境和已经尝试过的步骤发给我，后续会优先补充到排障手册。