不适合。游标将集合操作退化为串行循环，导致性能差、锁持有时间长、内存占用不可控，易引发OOM或系统拖慢；仅在必须逐行调用外部系统、强依赖上一行状态等不可替代场景才考虑，否则应优先使用UPDATE...FROM、窗口函数或CTE批量处理。
游标在SQL中真的适合逐行更新吗？
绝大多数情况下，不适合。游标本质是把集合操作退化为循环，性能差、锁持有时间长、内存占用不可控——尤其是当结果集大时，数据库常会缓存全部结果到临时空间，导致OOM或严重拖慢系统。真正需要逐行逻辑（比如调用存储函数、依赖上一行状态）才考虑游标，否则优先用 UPDATE ... FROM、窗口函数或CTE一次性处理。
如果必须用游标，如何避免内存爆炸？
关键不是“控制游标内存”，而是限制游标打开的数据量和生命周期。不同数据库策略略有差异：
- PostgreSQL：用
DECLARE ... SCROLL声明游标后，立刻用FETCH FORWARD N分批取数，避免FETCH ALL；配合CLOSE及时释放资源 - SQL Server：声明时加
LOCAL FAST_FORWARD READ_ONLY，禁用滚动和更新能力，减少锁和内存开销；每处理100–500行就CLOSE+ 重新DECLARE - MySQL：原生游标不支持分页取，必须靠
SELECT ... LIMIT offset, size模拟分批，用存储过程循环调用，每次只打开小结果集
示例（PostgreSQL）：
BEGIN; DECLARE batch_cursor CURSOR FOR SELECT id, value FROM logs WHERE status = 'pending' ORDER BY id; FETCH FORWARD 100 FROM batch_cursor; -- 处理这100行（用单独UPDATE或临时表） UPDATE logs SET status = 'done' WHERE id IN (...); CLOSE batch_cursor; COMMIT;
为什么 WHERE CURRENT OF 不推荐用于大批量更新？
它看似简洁，但隐含严重风险：
- 游标必须声明为
FOR UPDATE，会锁定整张表或大范围索引页，阻塞并发写入 - 数据库需维护游标位置与行的映射关系，数据量越大，定位越慢，内存占用呈线性增长
- 无法跳过错误行——某一行更新失败（如触发器报错），整个游标可能中断，难以恢复
更稳妥的做法是：用游标只读取 id 或主键，再用独立 UPDATE ... WHERE id = ? 执行，出错可 CONTINUE 或记录日志。
替代游标的低内存方案有哪些？
真正解决“逐行逻辑+内存可控”问题，应跳出游标思维：
- 用
UPDATE ... FROM（PostgreSQL/SQL Server）或UPDATE ... JOIN（MySQL）关联子查询，把计算逻辑下推到集合层 - 对需要状态累积的场景（如累计求和更新），改用窗口函数生成中间结果，再
UPDATE一次到位 - 超大数据量（千万级+）且逻辑复杂时，导出ID列表到应用层，用连接池+批量参数执行，内存由应用可控，失败可重试单批次
游标不是万能补丁，它的存在本身就在提醒你：当前设计可能没充分利用SQL的集合特性。
