一、问题现象与影响

MySQL连接数持续上升但未释放的现象，通常表现为监控系统中Threads_connected指标不断攀升，而Threads_cached和Threads_running无法有效回收空闲连接。这种异常会导致服务器资源耗尽，触发”Too many connections”错误（错误代码1040），最终造成应用服务不可用。

某电商平台案例显示，其数据库连接数在3小时内从200激增至5000，导致订单处理系统瘫痪45分钟。经排查发现，某微服务组件的连接池配置错误引发了级联效应。

二、核心原因深度解析

1. 连接泄漏的典型场景

（1）未关闭的连接对象：在Java应用中，未正确调用close()方法的Connection对象会持续占用连接。示例代码：

// 错误示例：try-with-resources未使用导致泄漏
public void queryData() {
    Connection conn = dataSource.getConnection(); // 未关闭
    Statement stmt = conn.createStatement();
    ResultSet rs = stmt.executeQuery("SELECT * FROM users");
    // 缺少conn.close()
}

（2）事务未提交：长时间运行的事务会持有连接，特别是在分布式事务场景下。MySQL的innodb_lock_wait_timeout默认50秒，超时后连接不会自动释放。

（3）连接池配置缺陷：HikariCP等连接池的maximumPoolSize设置过大，或idleTimeout/maxLifetime配置不合理，导致连接无法及时回收。

2. 配置不当的连锁反应

（1）全局参数失衡：

max_connections设置过高（如默认151→2000），掩盖了应用层问题
wait_timeout（默认28800秒）过长，导致空闲连接滞留
thread_cache_size过小，迫使系统频繁创建新线程

（2）用户权限问题：具有PROCESS权限的账户可通过SHOW PROCESSLIST查看所有连接，但无法终止异常连接，需SUPER权限配合KILL命令。

3. 应用架构设计缺陷

（1）连接复用率低：每个HTTP请求创建新连接，而非使用连接池。对比测试显示，连接复用可使吞吐量提升3-5倍。

（2）微服务雪崩效应：服务A的连接泄漏导致数据库连接耗尽，进而影响依赖服务B的正常运行，形成级联故障。

（3）ORM框架误用：Hibernate的hibernate.connection.release_mode设置为ON_CLOSE（默认）会导致连接延迟释放，建议改为AFTER_TRANSACTION。

三、系统性解决方案

1. 监控与诊断体系

（1）实时监控指标：

-- 关键监控SQL
SELECT 
    variable_value AS current_connections,
    (SELECT variable_value FROM performance_schema.global_variables 
     WHERE variable_name = 'max_connections') AS max_allowed,
    ROUND(variable_value/(SELECT variable_value FROM performance_schema.global_variables 
     WHERE variable_name = 'max_connections')*100,2) AS usage_percent
FROM performance_schema.global_status 
WHERE variable_name = 'Threads_connected';

（2）慢查询日志分析：通过log_slow_admin_statements和long_query_time参数定位异常SQL。

（3）进程级诊断：

-- 查看活跃连接详情
SELECT * FROM information_schema.processlist 
WHERE COMMAND != 'Sleep' AND TIME > 60 ORDER BY TIME DESC;

2. 配置优化策略

（1）动态参数调整：

-- 临时调整参数（重启失效）
SET GLOBAL max_connections = 1000;
SET GLOBAL wait_timeout = 300;  -- 5分钟

（2）连接池参数建议：

HikariCP配置示例：

HikariConfig config = new HikariConfig();
config.setMaximumPoolSize(50);       // 根据CPU核心数调整
config.setIdleTimeout(600000);       // 10分钟
config.setMaxLifetime(1800000);      // 30分钟
config.setConnectionTimeout(30000);  // 30秒

（3）线程缓存优化：

-- 计算合理thread_cache_size
SELECT (SELECT variable_value FROM performance_schema.global_status 
        WHERE variable_name = 'Threads_created') / 
       (SELECT variable_value FROM performance_schema.global_status 
        WHERE variable_name = 'Uptime') * 60 AS threads_per_minute;

3. 架构级改进方案

（1）读写分离实现：通过ProxySQL或MySQL Router实现自动路由，分散主库压力。

（2）连接池中间件：部署Pooled DBCP或Druid等中间件，统一管理连接生命周期。

（3）服务治理措施：

实现熔断机制：当连接数超过阈值时，拒绝新请求
实施限流策略：通过Sentinel或Resilience4j控制并发量
采用异步处理：将耗时操作转为消息队列处理

四、预防性措施

代码审查清单：
- 确保所有JDBC资源使用try-with-resources
- 验证事务边界是否正确
- 检查连接池配置是否与生产环境匹配
自动化测试：
- 集成连接泄漏检测工具（如LeakCanary for DB）
- 压测时监控连接数变化曲线
- 故障注入测试（模拟连接耗尽场景）

容量规划模型：

最大连接数 = (核心业务线程数 * 1.2) + (后台任务数 * 0.5) + 缓冲量

五、紧急处置流程

立即措施：

-- 终止异常连接（需SUPER权限）
KILL 12345;  -- 替换为实际PROCESS ID

临时扩容：

-- 动态提升连接上限（需评估服务器资源）
SET GLOBAL max_connections = 3000;

服务降级：
- 关闭非核心业务查询
- 启用只读副本
- 返回缓存数据

六、最佳实践总结

黄金配置组合：
- max_connections = MIN(服务器可用连接数0.8, 业务峰值需求1.5)
- wait_timeout = 300-600秒（根据应用类型调整）
- 连接池大小 = (核心线程数 * 2) + 缓冲量
监控告警规则：
- 连接数>80% max_connections时触发警告
- 持续5分钟>90%时触发严重告警
- 连接数增长率>10%/分钟时触发异常告警
持续优化机制：
- 每月进行连接数压力测试
- 每季度复审监控指标阈值
- 每次版本发布前进行连接泄漏检查

通过系统性地实施上述方案，可有效解决MySQL连接数只增不减的问题。实际案例显示，某金融系统在优化后，连接数稳定性提升92%，平均响应时间从2.3s降至0.8s，彻底消除了连接耗尽导致的业务中断风险。

MySQL连接数只增不减：问题溯源与优化实践指南