连接数过多的含义
数据库的连接数上限是一个硬性配额，达到上限后新连接会被直接拒绝，业务表现为登录失败、部分请求报错。触发原因可能是业务并发自然增长，也可能是连接没有被及时归还，比如应用侧连接池配置过大、长事务占用连接不放、异常重连不断堆积。
止血与治理要分开做
紧急情况下可以临时调高上限让业务先恢复，但这只是止血：每个连接都占用内存，上限调得过高会把压力转移到内存与调度上。真正解决问题需要回到来源侧，检查连接池上限之和是否超过数据库上限、是否存在长事务与空闲连接大量滞留。
基本信息
| 关键参数 | 最大连接数、当前连接数、运行线程数 |
|---|---|
| 观察入口 | 当前进程列表与会话状态统计 |
| 临时处置 | 动态调整上限，重启后按配置文件恢复 |
| 根治方向 | 连接池配置、超时回收、慢查询与长事务治理 |
典型使用场景
- 业务高峰期报连接数超限，需要快速恢复可用性
- 应用扩节点后连接数被迅速打满，需要重新规划配额
- 排查大量空闲连接来源，确认是否为连接泄漏
- 数据库迁移或割接期间连接数异常升高
- 容量评估时核算连接数上限与内存开销的平衡点
查看现状
查看现状
mysql -uroot -p -e "SHOW VARIABLES LIKE 'max_connections'"
mysql -uroot -p -e "SHOW STATUS LIKE 'Threads_connected'"
mysql -uroot -p -e "SHOW STATUS LIKE 'Threads_running'"
mysql -uroot -p -e 'SHOW PROCESSLIST' | head -30
# 关注 Sleep 状态连接的占比与持续时长止血与治理
止血与治理
mysql -uroot -p -e 'SET GLOBAL max_connections = 500' # 动态调整，重启前有效
# 治理方向：
# 1) 应用连接池上限与数据库上限一起规划，两者之和不超过数据库配额
# 2) 配置空闲连接回收与最大生存时间，避免长期占用
# 3) 治理慢查询与长事务，缩短连接持有时间
# 4) 抑制异常重连风暴，给重试加退避现象与判断
| 现象 | 可能原因 | 方向 |
|---|---|---|
| 新连接被拒绝 | 连接数达到上限 | 临时扩容并排查来源 |
| 大量空闲连接 | 应用未及时归还连接 | 检查连接池回收配置 |
| 运行线程数长期偏高 | 慢查询或长事务堆积 | 定位慢语句并优化 |
| 连接数阶梯式上升 | 服务扩容或重连风暴 | 核对实例数与重试策略 |
| 内存使用同步上升 | 连接内存开销累积 | 评估配额与内存的平衡 |
大幅调高上限会推高内存占用，连接内存乘以并发量可能直接影响数据库稳定性。先定位来源，再决定是治理还是扩容，避免把问题从连接层面转移到内存层面。