Cursor游标会造成阻塞吗

简短结论：Cursor（游标）本身不一定会阻塞，但它“用得不对”非常容易造成阻塞和性能问题。是否阻塞，取决于数据库类型、隔离级别、游标类型、是否加锁、以及事务是否长时间不提交。

下面分场景说清楚。

1. 什么情况下 Cursor 会“造成阻塞”

✅ 情况一：游标在事务中长时间不关闭 / 不提交

这是最常见的原因。

例如在 SQL Server / Oracle / PostgreSQL 中：

BEGIN TRANSACTION;

DECLARE cursor_name CURSOR FOR
SELECT * FROM orders WITH (UPDLOCK);

OPEN cursor_name;
-- 慢慢处理，几分钟不提交

➡ 游标持有的锁不会释放 ➡ 其他会话更新/读取相关行时被阻塞

✅ 阻塞来源不是“游标”，而是“未提交的事务 + 锁”

✅ 情况二：使用了“更新游标”（FOR UPDATE）

DECLARE cur CURSOR FOR
SELECT * FROM user WITH (UPDLOCK)

或 PostgreSQL：

DECLARE cur CURSOR FOR
SELECT * FROM user FOR UPDATE;

➡ 会逐行加锁 ➡ 其他事务修改这些行时会被阻塞

✅ 情况三：数据库游标默认是“服务器端游标”

以 SQL Server 为例：

• STATIC：快照，一般不阻塞
• DYNAMIC / KEYSET：可能持续加锁
• FAST_FORWARD：相对安全

如果游标是 DYNAMIC，并且事务很长： ➡ 会持续占用锁资源

2. 什么情况下 Cursor 不会阻塞

✅ 只读游标 + 自动提交

DECLARE cur CURSOR FOR
SELECT id FROM table;

并且：

• 没有 FOR UPDATE
• 没有显式事务
• 游标很快关闭

➡ 基本不会阻塞

✅ 客户端游标（如 JDBC / Python）

例如 Python：

cursor.execute("SELECT * FROM table")
for row in cursor:
    ...

• 实际上是一次性取数据
• 服务端不长期持有游标
• 不容易阻塞

3. 常见数据库情况对比

4. 如何避免 Cursor 造成阻塞（重点）

✅ 1. 尽量不用游标（用集合操作）

UPDATE table SET status = 1 WHERE status = 0;

比逐行游标快且安全。

✅ 2. 必须用时：

• 用 READ ONLY
• 用 FAST_FORWARD（SQL Server）
• 避免 FOR UPDATE
• 小批量处理 + 及时提交

WHILE ...
BEGIN
   -- 处理 100 行
   COMMIT;
END

✅ 3. 缩短事务生命周期

游标 ≠ 阻塞 长事务 + 锁 = 阻塞

5. 一句话总结

Cursor 本身不“必然”阻塞，但游标 + 锁 + 长事务 = 阻塞高危组合。

如果你愿意，可以告诉我：

• 用的是哪种数据库（SQL Server / Oracle / PG / MySQL）
• 是存储过程游标还是代码里用的
• 是否涉及更新

我可以直接帮你判断“你这个游标会不会阻塞”。