游标在存储过程中不能直接分步提交，因为DECLARE CURSOR必须在事务内声明，而COMMIT会隐式关闭所有活动游标，导致后续FETCH失败；可行方案是将分步提交移至游标循环外，按批次控制事务边界，或采用只读游标+应用层分发+批量DML的组合方式。
游标在存储过程中为什么不能直接分步提交
因为 SQL 标准和主流数据库（如 SQL Server、PostgreSQL、Oracle）都规定：DECLARE CURSOR 必须在事务内声明，而一旦开启显式事务（BEGIN TRANSACTION），游标遍历期间的 COMMIT 会隐式关闭所有活动游标——这不是 bug，是事务隔离机制决定的。你看到的“游标无效”或“fetch status -1”错误，大概率是 COMMIT 后还试图 FETCH NEXT 导致的。
真正可行的路径只有一条：把“分步提交”从游标循环内部移出来，改为按批次控制事务边界。
- 用
WHILE循环 +TOP N（SQL Server）或LIMIT（PostgreSQL）模拟游标分页，每次查一批数据，处理完再COMMIT - 避免
DECLARE CURSOR ... FOR UPDATE配合循环内提交——它在多数引擎中根本不可行 - 若必须用游标（比如需要逐行判断是否跳过某行），则整个游标生命周期必须包裹在单个事务中，分步提交只能靠应用层协调
SQL Server 中用 TOP + OFFSET 实现安全的分批提交
比起传统游标，OFFSET-FETCH 更轻量、可预测，且天然支持事务分界。关键是要用变量控制批次起点，并在每次循环后更新偏移量。
DECLARE @BatchSize INT = 1000;
DECLARE @Offset INT = 0;
DECLARE @TotalRows INT;
<p>SELECT @TotalRows = COUNT(*) FROM orders WHERE status = 'pending';</p><p>WHILE @Offset </p><pre class="brush:php;toolbar:false;">UPDATE TOP (@BatchSize) o
SET status = 'processed', updated_at = GETDATE()
FROM orders o
WHERE o.status = 'pending'
AND o.id IN (
SELECT id FROM (
SELECT id, ROW_NUMBER() OVER (ORDER BY id) AS rn
FROM orders WHERE status = 'pending'
) t WHERE t.rn > @Offset AND t.rn <p>END
</p>注意：ROW_NUMBER() 必须有确定性排序（如 id），否则同一批次可能漏行或重复；WAITFOR DELAY 不是必需，但在高并发更新时能缓解日志写入压力。
PostgreSQL 中用 cursor + MOVE + COMMIT 的替代方案
PostgreSQL 允许在事务外声明游标（DECLARE foo NO SCROLL CURSOR WITH HOLD FOR ...），但 WITH HOLD 游标不支持 FOR UPDATE，也不能跨事务修改数据。所以实际能走通的只有“只读游标 + 应用层分发 + 批量 DML”这条路。
- 先用
DECLARE my_cursor SCROLL CURSOR FOR SELECT id, amount FROM payments WHERE processed = false ORDER BY id声明可滚动游标 - 用
MOVE FORWARD 1000 IN my_cursor跳过前 N 行（不取数据，只移动位置） - 再用
FETCH 1000 FROM my_cursor拿到一批 ID，拼成UPDATE ... WHERE id IN (...)提交 - 每次
FETCH后手动COMMIT，然后重新DECLARE新游标（因旧游标已在事务结束时释放）
这种模式本质是“游标仅作分页索引”，真实更新靠批量语句完成，既规避了游标状态丢失，又保留了顺序可控性。
最容易被忽略的锁与性能陷阱
很多人以为分批提交就能避免长事务，但没意识到：如果 WHERE 条件无法命中索引，每次 UPDATE TOP (@BatchSize) 都会触发全表扫描+全表锁（SQL Server）或大范围 SI 锁（PostgreSQL）。结果是吞吐没上去，阻塞反而更频繁。
- 务必确认
WHERE字段（如status）上有有效索引；更优的是复合索引，例如CREATE INDEX IX_orders_status_id ON orders(status, id) - 避免在循环中执行
SELECT COUNT(*)计算总行数——它本身就会成为瓶颈；改用估算值或业务侧预估 - PostgreSQL 中
FOR UPDATE SKIP LOCKED可用于多进程并发消费队列场景，但它不适用于单进程分批，因为会打乱顺序
真正的分步提交难点不在语法，而在如何让每一批操作都落在索引驱动的窄范围上——否则只是把一个大锁，拆成了十几个小锁而已。
