mysql存储过程执行过长会阻塞连接归还，因其可能含长事务、未提交操作、显式锁或慢查询，导致连接长时间占用；需通过show full processlist定位、explain分析sql、确保commit/rollback、避免非db操作、用try-with-resources关闭callablestatement、消费全部结果集，并合理规划连接池容量。
MySQL存储过程执行时间过长，阻塞连接归还
存储过程本身不直接“耗尽”连接池，但若它内部包含长事务、未提交操作、显式锁（如 SELECT ... FOR UPDATE）、或嵌套循环+慢查询，就会让连接长时间处于 Query 或 Locked 状态，无法及时归还给池。此时连接池的 activeCount 持续高位，新请求只能排队或超时。
实操建议：
- 在 MySQL 中执行
SHOW FULL PROCESSLIST，筛选出Command = 'Query'且Time> 30 秒的线程，用Info字段确认是否为存储过程调用（如CALL proc_name(...)） - 对目标存储过程加
EXPLAIN分析（需先拆解其核心 SQL，或在过程内加日志表记录执行步骤耗时） - 检查过程内是否遗漏
COMMIT或ROLLBACK—— 特别是在异常分支中，未回滚会导致事务长期挂起，连接被锁死 - 避免在存储过程中做非数据库操作（如 HTTP 调用、文件读写），这些会无谓延长连接占用时间
Java 应用中调用存储过程后未正确关闭资源
最常见却最易被忽略的坑：用 CallableStatement 调用存储过程时，只关了 ResultSet 或漏关 CallableStatement 本身，导致底层物理连接未释放。即使用了连接池，该连接仍被标记为“忙”，无法复用。
实操建议：
- 强制使用
try-with-resources，确保CallableStatement和任意ResultSet都在作用域结束时自动关闭：try (CallableStatement cs = conn.prepareCall("{CALL proc_user_stats(?)}")) { cs.setInt(1, userId); cs.execute(); } - 若必须手动管理，务必在
finally块中按ResultSet → CallableStatement → Connection顺序关闭（虽然 Connection 通常由池管理，但显式 close() 是归还信号） - 启用连接泄露检测：以 HikariCP 为例，设
leakDetectionThreshold=60000（60 秒），一旦调用后 60 秒未归还，日志会打印堆栈，精准定位哪行代码漏关
存储过程返回多个结果集，未全部消费导致连接卡住
MySQL 存储过程可通过多个 SELECT 语句返回多个结果集（ResultSet）。JDBC 默认要求客户端**逐个获取并关闭所有结果集**，否则连接会一直等待后续结果，表现为 “Sleep” 状态但实际被占用。
实操建议：
- 调用后立即循环消费所有结果集：
boolean hadResults = cs.execute(); while (hadResults) { try (ResultSet rs = cs.getResultSet()) { // 处理 rs } hadResults = cs.getMoreResults(); } - 若确定过程只返回单个结果或无结果，可在连接 URL 加参数
useServerPrepStmts=false&cachePrepStmts=true并配合cs.setFetchSize(1)减少缓冲压力 - 避免在 MyBatis 等框架中用
@Select("{CALL ...}")直接映射多结果集——它默认只取第一个，其余静默丢失，连接却未释放
连接池配置与存储过程并发量不匹配
一个耗时 2 秒的存储过程，在 QPS=50 的场景下，理论最低需要 100 个连接（50 × 2）。若池最大值设为 20，必然排队溢出。这不是代码 bug，而是容量规划失误。
实操建议：
- 用压测工具（如 JMeter）模拟真实调用频率和过程耗时，测算所需连接数下限：
maxPoolSize ≥ 平均QPS × 95分位响应时间（秒） - 不要盲目调大
maximumPoolSize—— MySQL 的max_connections有硬上限，且每个连接消耗内存（约 2–3 MB），超过会导致 OOM - 更优解是优化存储过程本身：拆分大事务、加索引、用临时表替代子查询、将部分计算移到应用层 —— 把 2 秒降到 200ms，连接需求直接降为 1/10
SHOW PROCESSLIST 里一堆 CALL xxx 卡在 Updating 或 Sending data 时，你得快速判断：是 SQL 逻辑缺陷、索引缺失，还是应用层根本没走完结果集消费流程。这两个地方一错，监控再全也救不回连接。
