SQL游标是面向集合的SQL中实现逐行处理的补充机制，适用于跨行状态累积、异构系统调用、复杂条件分支更新及调试探查等场景；应优先用窗口函数、CTE递归、批量操作或应用层流式处理替代。
SQL 游标（CURSOR）本质是面向集合的 SQL 语言中引入的一种**逐行处理机制**，它并非万能工具，而是在特定场景下弥补集合操作局限性的补充手段。过度依赖游标往往暴露设计或逻辑缺陷，真正关键的是：明确什么情况非用不可、如何写得安全高效、以及怎样用更优方式替代。
哪些场景确实需要游标？
不是所有“要循环”都该用游标。以下几类问题在标准 SQL（尤其 SQL Server、Oracle 等）中缺乏等效集合解法时，游标仍是合理选择：
- 跨行状态累积计算：如按时间序计算滚动余额、动态加权移动平均，且窗口函数不支持所需逻辑（如依赖前一行计算结果再参与当前行运算）；
- 异构数据源逐条调用外部系统：例如遍历订单表，对每条记录调用 HTTP API 更新第三方库存，这类 I/O 绑定任务难以并行化；
- 复杂业务规则驱动的条件分支更新：比如根据客户等级、历史行为、实时风控评分组合判断，每条记录需独立执行多步验证与不同字段更新；
- 调试与数据探查阶段的可控遍历：开发过程中临时检查中间状态、打点日志、分批验证逻辑正确性。
避免常见性能陷阱
游标慢，往往不是因为“逐行”，而是因为写法不当。核心优化方向是减少资源占用与上下文切换：
- 显式声明最简游标类型：优先用 FAST_FORWARD（SQL Server）或 FOR READ ONLY + NO SCROLL（PostgreSQL/Oracle），禁用默认的可滚动、可更新、敏感游标；
- 缩小游标结果集范围：WHERE 条件必须走索引；避免在游标定义中用子查询或函数包裹过滤字段；
- 关闭自动提交与减少事务粒度：不在游标循环内频繁 COMMIT；若需事务保障，改用批量提交（如每 100 行 COMMIT 一次），而非每行一事务；
- 用变量代替多次 FETCH INTO 字段列表：尤其当游标字段多时，直接 FETCH INTO @var1, @var2... 比 FETCH INTO @table_var 更轻量；
- 及时释放资源：DEALLOCATE 游标必须放在异常处理块（TRY/CATCH 或 EXCEPTION）之后，防止连接泄漏。
比游标更好的替代方案
多数所谓“必须循环”的需求，其实可用集合操作+高级语法替代，性能提升常达数量级：
- 窗口函数替代累计逻辑：SUM() OVER (ORDER BY ...)、LAG()/LEAD()、FIRST_VALUE() 等可覆盖 80% 的跨行计算；
- CTE + 递归查询替代层级遍历：组织架构、BOM 展开、路径查找等，用 WITH RECURSIVE 更清晰且可优化；
- 临时表 + 批量 UPDATE/INSERT：将“逐条判断更新”转为先 SELECT INTO #temp 标记目标行，再用单条 UPDATE JOIN 完成；
- 应用层流式处理：把游标逻辑移到应用代码（如 Python pandas chunking、Java JDBC streaming result set），利用内存计算与并行能力，数据库只负责读取原始集。
一个安全游标模板（SQL Server）
以下是最小化风险的写法范例，含错误捕获与资源清理：
DECLARE @id INT, @amount DECIMAL(10,2); DECLARE order_cursor CURSOR FAST_FORWARD FOR SELECT id, amount FROM orders WHERE status = 'pending' AND created_date >= '2024-01-01'; <p>OPEN order_cursor; FETCH NEXT FROM order_cursor INTO @id, @amount;</p><p>WHILE @@FETCH_STATUS = 0 BEGIN BEGIN TRY -- 业务逻辑（避免长事务、大计算） UPDATE orders SET processed = 1 WHERE id = @id;</p><pre class="brush:php;toolbar:false;">FETCH NEXT FROM order_cursor INTO @id, @amount;
END TRY BEGIN CATCH -- 记录错误但不停止整体流程 INSERT INTO error_log VALUES (@id, ERROR_MESSAGE()); FETCH NEXT FROM order_cursor INTO @id, @amount; END CATCH END
CLOSE order_cursor; DEALLOCATE order_cursor;
