网站响应忽然变慢，页面加载圈持续旋转，错误日志中陆续出现连接超时、获取连接失败等记录，这类情况通常不属于常规的性能起伏。一般性的卡顿表现为响应变慢但请求最终仍可完成，而连接池耗尽更像是入口被堵死，新请求无法取得可用连接，只能排队或直接失败。两者在监控图形上也有差异，前者多呈现响应时间缓慢攀升，后者则往往伴随活跃连接数达到上限、等待队列不断增长。
排查的第一环节是判断连接是否被长时间占用。可以先查看数据库端的当前会话列表，观察哪些连接处于执行状态、哪些处于空闲但未释放状态。如果大量连接长时间停留在执行状态，通常与慢查询有关，需要结合执行计划判断是否缺少索引或扫描数据量过大。如果连接处于空闲状态却久久不归还，则更可能是应用侧没有正确释放。若两者都不突出，但连接数在短时间内快速上涨，就要考虑突发流量或短连接频繁创建。
第二环节是检查应用侧的连接释放逻辑与超时设置。需要逐项核对的参数包括连接获取超时时间、连接空闲超时时间、连接最大存活时间、连接泄漏检测阈值以及事务提交与回滚的边界。常见问题是异常分支中没有关闭连接，或者事务未正确结束导致连接被挂起。另外，连接池的最大连接数设置过小，也会在高并发时迅速触顶。核对时建议结合代码审查与日志追踪，确认每次获取连接后都有对应的释放路径。
第三环节是检查数据库侧的最大连接数与等待队列。数据库允许的最大连接数是硬上限，如果应用侧配置的总连接数接近或超过这个值，就会出现互相抢占。此时要判断是容量不足还是使用不当。若业务量确实增长，连接数长期处于高位，属于容量问题；若连接数忽高忽低且伴随大量空闲连接，则更可能是使用方式问题。等待队列的长度和等待时间也能提供线索，队列持续增长说明释放速度跟不上获取速度。
第四环节是给出临时缓解与长期调整的顺序建议。临时缓解可以先重启应用释放泄漏连接，或适当调大连接池上限，但这只是争取时间，不能替代根因修复。长期调整应从修复未释放连接、优化慢查询、合理设置超时参数入手，再评估是否需要扩容数据库连接数。任何变更前都要先备份当前配置，并记录调整前的连接数基线、响应时间基线，便于对比效果。
一套可复用的排查清单可以这样组织：先看数据库当前会话状态，再查慢查询与空闲连接，接着核对应用侧释放逻辑与超时参数，然后对比数据库最大连接数与实际使用量，最后按先止血后治本的顺序处理。过程中保持配置备份和基线记录，避免反复调整失去参照。具体参数含义和调整方式，应以实际运行环境和数据库官方文档为准。
