MySQL连接池耗尽问题分析与优化实践

1. 问题现象与初步排查

最近在开发一个数据导出功能时，遇到了一个典型的MySQL连接问题：com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure。这个错误表面看起来像是网络连接问题，但实际排查后发现网络完全正常。错误发生时，前端页面卡住无响应，后端日志中频繁出现这个异常。

通过数据库管理工具执行show processlist命令后，发现了一个关键现象：存在大量长时间运行的查询进程，状态多为"Sleep"或"Query"，持续时间普遍超过30秒。这些长连接占用了连接池资源，导致新请求无法获取数据库连接。

重要提示：遇到这类错误时，第一步永远是检查网络连通性。确认网络正常后，再深入排查其他可能性。

2. 问题根源分析

2.1 事务范围过大导致连接占用

问题的直接诱因是在一个复杂方法上添加了@Transactional注解。这个方法执行时间较长（约2分钟），期间进行了多次数据库操作。由于事务未提交，数据库连接一直被占用，最终导致连接池耗尽。

java复制@Transactional(rollbackFor = Exception.class)
public void exportReport(ReportParams params) {
    // 复杂的数据查询和处理逻辑
    List<Data> dataList = queryData(params);
    processData(dataList);
    generateReport(dataList);
}

2.2 连接池配置不合理

项目使用的是Druid连接池，默认配置如下：

• 初始连接数：5
• 最大连接数：20
• 获取连接超时时间：30秒

当多个用户同时执行这个导出操作时，连接很快被耗尽。后续请求要么等待超时，要么直接失败。

2.3 SQL查询效率低下

通过EXPLAIN分析发现，部分查询没有使用索引，进行了全表扫描。一个本应毫秒级完成的查询，实际执行需要数秒，进一步加剧了连接占用问题。

3. 解决方案与实施步骤

3.1 优化事务范围

将大事务拆分为多个小事务，只在必要