排查MySQL连接池问题需从数据库、应用和网络三方面入手。1. 检查max_connections与Threads_connected，判断是否连接耗尽；2. 通过show processlist和慢查询日志分析连接状态与SQL性能；3. 审查连接池配置（最大连接、超时时间）及代码是否存在连接泄漏；4. 启用general log追踪连接行为，结合系统资源与网络状况综合诊断，定位资源不足、SQL阻塞或连接未释放问题。
排查 MySQL 连接池问题需要从数据库端、应用端和网络环境三方面入手，重点观察连接数、等待状态、超时配置和资源使用情况。以下是具体排查方法。
1. 检查当前连接数和最大连接限制
MySQL 允许的最大连接数由 max_connections 参数控制，如果应用请求的连接超过这个值，就会出现“Too many connections”错误。
查看当前设置：
show variables like 'max_connections';查看当前活跃连接数：
show status like 'Threads_connected';若 Threads_connected 接近或达到 max_connections，说明连接池已满。可临时增加最大连接数（需评估服务器负载能力）：
set global max_connections = 500;2. 分析连接状态和慢查询
使用以下命令查看当前连接的状态：
show processlist;重点关注：
- State：是否长时间处于 “Sending data”、“Locked”、“Copying to tmp table” 等状态
- Time：执行时间过长的连接可能占用连接不释放
- Info：正在执行的 SQL 是否存在性能问题
结合慢查询日志分析耗时操作：
show variables like 'slow_query_log'; show variables like 'long_query_time';开启慢查询日志有助于定位长期占用连接的 SQL。
3. 检查连接池配置与连接泄漏
应用层连接池（如 HikariCP、Druid、C3P0）配置不当会导致连接无法回收或频繁创建销毁。
常见检查点：
- 最大连接数：是否与数据库 max_connections 匹配
- 空闲超时（idle_timeout）：空闲连接多久被回收
- 连接生命周期（max_lifetime）：连接最大存活时间，避免长时间持有
- 连接获取超时（connection_timeout）：应用等待连接的最长时间
若发现连接数持续增长且无下降趋势，可能是连接未正确关闭，即“连接泄漏”。检查代码中是否有：
- 未在 finally 块或 try-with-resources 中关闭 Connection、Statement、ResultSet
- 异步任务中获取连接后未主动释放
4. 监控和日志分析
启用 MySQL 的 general log 可追踪连接建立和断开（仅用于排查，生产慎用）：
set global general_log = ON; set global log_output = 'table';然后查询：
select * from mysql.general_log where argument like '%connect%';同时监控系统资源：
- CPU、内存使用率是否过高导致响应变慢
- 网络延迟或丢包影响连接稳定性
- 连接池监控指标（如 active、idle、pending 连接数）
基本上就这些。关键是结合数据库状态、应用配置和代码逻辑综合判断，定位是资源不足、SQL 性能差还是连接未释放。
