Java调用SQL Server游标存储过程需Sleep才生效的原因

这种情况大概率是Java端的操作没有等待存储过程完全执行完毕就提前终止了资源（比如数据库连接），或是事务提交时机不匹配导致的，下面具体分析几个常见原因：

1. JDBC连接过早关闭/未等待存储过程执行完成 #

当你用Java调用存储过程时，如果代码在调用execute()或call()之后，没有等待游标遍历删除的逻辑全部完成就直接关闭了数据库连接，或者触发了事务的提交/回滚，SQL Server的游标进程就会被中断，导致部分记录没来得及删除。

举个典型的错误代码示例：

try (Connection conn = getConnection()) {
    CallableStatement cs = conn.prepareCall("{call SP_PURGA(?)}");
    cs.setInt(1, 30);
    cs.execute();
    // 连接自动关闭，但游标可能还在后台遍历删除
}

游标遍历删除是需要时间的，而JDBC默认不一定会一直阻塞到存储过程的所有逻辑执行完毕（尤其是游标这种迭代操作）。加上Thread.sleep(30000)相当于给了足够的缓冲时间，让游标把所有待删记录处理完，再关闭连接。

2. 事务上下文冲突 #

如果Java代码开启了事务，但没有等待存储过程内部的事务（若有）完成就提前提交，会导致部分删除操作被中断甚至回滚。比如存储过程里的游标操作在独立事务中执行，而Java端的事务提前提交，直接终止了存储过程的事务逻辑。

另外，若SQL Server使用了异步游标（比如非FAST_FORWARD类型的游标，或驱动配置了异步执行），JDBC驱动可能会提前返回执行结果，实际游标还在后台处理，此时Java代码继续执行关闭资源，就会中断后台的游标操作。

3. 锁等待或资源竞争 #

存储过程用游标删除记录时，可能遇到其他会话持有目标记录的锁，导致游标需要等待锁释放才能继续删除。如果Java端没有给足够的等待时间，就会在游标还在等待锁的时候中断操作，留下未删除的记录。加上sleep后，游标有足够时间等待锁释放，完成所有删除逻辑。

不用sleep的正确解决方式 #

依赖Thread.sleep()只是临时 workaround，更可靠的做法是：

• 强制JDBC等待存储过程执行完毕：调用execute()后，循环处理所有结果集和更新计数，确保存储过程逻辑完全执行：

  CallableStatement cs = conn.prepareCall("{call SP_PURGA(?)}");
  cs.setInt(1, 30);
  boolean hasResults = cs.execute();
  // 循环处理直到没有更多结果/更新
  while (hasResults || cs.getUpdateCount() != -1) {
      if (hasResults) {
          cs.getResultSet().close();
      }
      hasResults = cs.getMoreResults();
  }
  

• 统一事务上下文：确保存储过程的事务设置与Java端兼容，比如存储过程若用SET XACT_ABORT ON，Java端不要提前提交事务。
• 替换游标为批量删除：游标本身效率低下，建议直接用条件批量删除替代（比如DELETE FROM 表名 WHERE 时间列 < DATEADD(day, -@iDIAS_P, GETDATE())），从根本上避免游标带来的执行延迟和资源问题。

内容的提问来源于stack exchange，提问作者JesusLopez