1. 问题现象与紧急处理

当MySQL突然抛出"Too many connections"错误时，整个系统可能瞬间陷入瘫痪状态。这个报错意味着所有可用连接都被占用，新的客户端无法建立连接。作为DBA，我处理过数十次这类生产事故，总结出一套快速止血方法论。

1.1 30秒应急处理方案

遇到连接爆满时，按这个优先级操作：

1. 立即释放空闲连接（最快速有效）：

-- 查看所有连接状态 SHOW PROCESSLIST; -- 批量清理Sleep状态的空闲连接（危险操作，需评估业务影响） SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist WHERE Command = 'Sleep' AND Time > 300 INTO OUTFILE '/tmp/kill_idle.sql'; SOURCE /tmp/kill_idle.sql;

2. 临时扩容连接数（治标不治本）：

-- 不重启服务的情况下动态调整 SET GLOBAL max_connections = 500;

3. 超级管理员通道（最后手段）： 如果普通账号已无法连接，使用--skip-grant-tables参数启动MySQL，但会带来严重安全隐患，操作后必须立即恢复。

警告：KILL操作可能导致事务中断，高并发时段慎用。我曾遇到某电商大促时误杀支付事务连接，导致订单状态不一致的惨痛教训。

2. 根因分析与深度排查

2.1 连接泄漏的三大典型场景

通过分析上百个案例，我发现连接泄漏主要有这些模式：

1. 连接池配置不当：

• 最大连接数设置过高（超过实例内存承受能力）
• 最小空闲连接数设置不合理
• 未正确配置连接回收策略

2. 应用层资源未释放：

// 典型错误示例：未关闭的连接 try { Connection conn = dataSource.getConnection(); // 业务代码... // 忘记conn.close() } catch (Exception e) { // 异常处理... }

3. 慢查询堆积：

-- 查看运行时间超过30秒的查询 SELECT * FROM information_schema.processlist WHERE Command != 'Sleep' AND Time > 30 ORDER BY Time DESC;

2.2 诊断工具箱

这是我的常用排查命令组合：

-- 查看连接数使用情况 SHOW STATUS LIKE 'Threads_connected'; SHOW VARIABLES LIKE 'max_connections'; -- 按客户端IP统计连接数 SELECT SUBSTRING_INDEX(HOST,':',1) AS client_ip, COUNT(*) AS connection_count FROM information_schema.processlist GROUP BY client_ip ORDER BY connection_count DESC; -- 检查是否有事务长时间未提交 SELECT * FROM information_schema.innodb_trx ORDER BY trx_started ASC LIMIT 10;

3. 连接池优化实战

3.1 Druid连接池黄金配置

以阿里Druid为例，推荐生产环境配置：

# 基础配置 druid.initialSize=5 druid.maxActive=50 druid.minIdle=5 # 关键回收策略 druid.testWhileIdle=true druid.timeBetweenEvictionRunsMillis=60000 druid.minEvictableIdleTimeMillis=300000 druid.validationQuery=SELECT 1 # 泄漏检测 druid.removeAbandoned=true druid.removeAbandonedTimeout=300 druid.logAbandoned=true

3.2 不同场景下的参数调整

1. 突发流量场景：

druid.maxActive=100 druid.maxWait=5000 # 适当增加等待超时

2. 定时任务场景：

druid.timeBetweenConnectErrorMillis=30000 # 避免频繁重试

3. 微服务场景：

druid.filters=stat,wall # 开启SQL防火墙

4. 长效预防机制

4.1 监控体系建设

建议配置这些监控项：

1. 连接数使用率阈值告警（>80%）
2. 长时间运行事务监控（>30s）
3. 连接获取时间监控（>1s）

Prometheus示例配置：

- alert: MySQLHighConnections expr: mysql_global_status_threads_connected / mysql_global_variables_max_connections > 0.8 for: 5m labels: severity: warning annotations: summary: "MySQL连接数使用率过高 (instance {{ $labels.instance }})" description: "当前连接数: {{ $value }}%"

4.2 压力测试建议

使用sysbench进行连接池压测：

sysbench oltp_read_write \ --db-driver=mysql \ --mysql-host=127.0.0.1 \ --mysql-port=3306 \ --mysql-user=test \ --mysql-password=test \ --mysql-db=sbtest \ --threads=100 \ --time=300 \ --report-interval=10 \ prepare

5. 典型案例分析

5.1 电商秒杀事故复盘

某次618大促期间，MySQL连接数突然飙升至上限。通过分析发现：

1. 商品详情页没有启用缓存，直接穿透到DB
2. 连接池maxActive设置过小（仅20）
3. 没有熔断机制，持续重试导致雪崩

解决方案：

1. 增加Redis缓存层
2. 调整连接池参数：

druid.maxActive=200 druid.maxWait=1000 # 快速失败

3. 引入Hystrix熔断

5.2 连接泄漏的隐蔽案例

某金融系统每天凌晨准时出现连接泄漏，最终发现是报表生成任务中：

def generate_report(): conn = get_connection() # 没有try-finally块 # 生成报表代码... if report_type == 'complex': return # 提前返回导致conn未关闭 conn.close()

修复方案：

1. 使用上下文管理器确保连接释放
2. 添加连接泄漏检测日志
3. 设置合理的超时时间

6. 高级技巧与工具

6.1 Performance Schema分析

启用高级监控：

-- 开启连接追踪 UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_waits%'; -- 查看连接等待事件 SELECT * FROM performance_schema.events_waits_history_long WHERE EVENT_NAME LIKE 'wait/io/socket%';

6.2 pt-kill自动清理工具

配置智能kill规则：

pt-kill --host=localhost --user=monitor --password=xxx \ --match-command=Query --busy-time=60 --kill --print

7. 架构层面的优化

对于高并发系统，建议：

1. 读写分离降低主库压力
2. 使用ProxySQL实现连接池复用
3. 重要业务使用独立实例
4. 考虑使用MySQL线程池插件

线程池配置示例：

[mysqld] thread_handling=pool-of-threads thread_pool_size=32 thread_pool_max_threads=1000

我在实际运维中发现，合理的连接池配置配合完善的监控，可以预防90%的连接数问题。特别是在微服务架构下，每个服务都应独立评估自己的连接需求，避免"连接风暴"影响整个数据库集群。