SQL Server 的查询语句执行后默认返回一个结果集，这是关系数据库最自然的工作单元。结果集由数据库引擎在内部完成筛选、连接、分组和排序，再统一发送给客户端。游标则不同，它允许开发者逐行访问查询结果中的每一行，在 T-SQL 中实现类似过程式编程的循环逻辑。两者适用场景不一样，混用会造成不必要的锁竞争和内存消耗。
结果集与游标的基本差异
结果集是 SQL Server 处理 SELECT 语句时生成的完整数据集合，它由存储引擎根据执行计划一次性计算并返回。在执行计划中，优化器可以把多个表之间的 JOIN、WHERE 过滤、GROUP BY 聚合等操作转换成基于集合的算法，例如哈希匹配、合并连接和嵌套循环。对于大多数关系型任务，结果集是最高效的方式，因为它让数据库内核充分发挥批处理能力，减少了客户端与服务器之间的交互次数。
游标则提供了一种单行访问接口。它先把查询结果放入一个临时结构，再通过 FETCH 操作一行一行读取。SQL Server 支持多种游标类型，包括静态游标、动态游标、只进游标和键集驱动游标。不同的游标类型在数据一致性、可更新能力和资源占用上有明显差异。比如静态游标会在 tempdb 中建立快照，对源表的后续修改不会反映到游标结果中；动态游标则会尽量反映源数据变化，但需要更多的资源和锁。
二者核心区别在于处理模型：结果集是基于集合的声明式操作，游标是基于行的命令式操作。SQL Server 优化器无法像优化普通查询那样优化游标的逐行逻辑，因此游标中的 SELECT 虽然可能使用了索引，但每行 FETCH 的累计开销仍然很高。下面的表格简要归纳了主要差异。
| 对比维度 | 结果集 | 游标 |
|---|---|---|
| 处理模型 | 基于集合 | 基于行 |
| 执行方式 | 一次性计算并返回 | 逐行提取和循环 |
| 优化器参与度 | 高，可选择最优计划 | 低，逐行逻辑难以优化 |
| 资源占用 | 相对较低 | 较高，常使用 tempdb 和额外锁 |
| 典型场景 | 连接、聚合、批量更新 | 调用外部过程、顺序依赖、小型循环 |
游标的完整使用步骤与代码示例
在存储过程或脚本中使用游标，必须遵循固定顺序：声明游标、打开游标、提取数据、循环处理、关闭游标、释放游标。任何一个环节遗漏都可能导致资源泄漏或连接会话中的临时对象残留。下面通过一个典型示例，展示如何遍历销售表并逐行更新汇总表。
DECLARE @order_id INT;
DECLARE @customer_id INT;
DECLARE @amount DECIMAL(10,2);
DECLARE order_cursor CURSOR LOCAL FORWARD_ONLY STATIC READ_ONLY FOR
SELECT order_id, customer_id, amount
FROM dbo.sales_orders
WHERE order_status = 1;
OPEN order_cursor;
FETCH NEXT FROM order_cursor INTO @order_id, @customer_id, @amount;
WHILE @@FETCH_STATUS = 0
BEGIN
UPDATE dbo.customer_summary
SET total_amount = total_amount + @amount
WHERE customer_id = @customer_id;
FETCH NEXT FROM order_cursor INTO @order_id, @customer_id, @amount;
END;
CLOSE order_cursor;
DEALLOCATE order_cursor;
这段代码使用了 LOCAL、FORWARD_ONLY、STATIC、READ_ONLY 四个选项。LOCAL 表示游标作用域仅在当前批处理或存储过程中，不会因为调用堆栈的结束而残留。FORWARD_ONLY 只能向前提取，STATIC 会在 tempdb 中创建快照，READ_ONLY 禁止通过游标更新源行。这四个选项组合起来可以降低资源占用，适合只读逐行处理的场景。
需要注意 @@FETCH_STATUS 返回 0 时表示 FETCH 成功，-1 表示提取失败或超出结果集末尾，-2 表示所请求的行已被删除。循环条件必须使用 = 0，并且在循环体内要继续 FETCH NEXT，否则容易形成死循环。游标使用完毕后必须 CLOSE 和 DEALLOCATE，CLOSE 释放当前结果集和锁，DEALLOCATE 移除游标定义本身，只执行其中一个仍然可能留下部分内存结构。
游标性能开销分析与替代方案
游标的性能问题主要来自三个方面。第一，每次 FETCH 都是一次独立的网络或内存往返，如果结果集有几十万行，开销会线性放大。第二，游标可能长时间持有共享锁或更新锁，阻塞其他事务。尤其是默认的动态游标，对源数据的导航会引入额外锁和版本信息。第三，SQL Server 需要消耗 tempdb 空间存储游标数据，静态游标和键集驱动游标尤为明显。
对于循环更新或累计计算，可以优先考虑基于集合的 UPDATE 语句。很多原本需要游标逐行处理的任务，通过自连接、CASE 表达式或派生表就可以完成。例如上一个游标示例中按客户汇总销售额，可以直接写成一条集合更新语句。
UPDATE cs
SET total_amount = cs.total_amount + src.order_amount
FROM dbo.customer_summary AS cs
JOIN (
SELECT customer_id, SUM(amount) AS order_amount
FROM dbo.sales_orders
WHERE order_status = 1
GROUP BY customer_id
) AS src
ON cs.customer_id = src.customer_id;
这段语句把原来的逐行累加改为一次聚合连接，优化器可以选择合适的连接算法和索引。即使汇总表需要按订单状态分别累加，也只需在派生表中增加分组列，逻辑仍然保持集合方式。SQL Server 在执行这样的 UPDATE 时，会尽量减少每行更新的日志开销，整体性能通常远高于游标。
还有一些场景需要生成行号、排名或前后行差值，这些也可以通过窗口函数替代游标。例如 ROW_NUMBER、LAG、LEAD、SUM OVER 等。窗口函数在 SQL Server 2005 之后已经成熟，它们的执行计划通常基于排序或哈希，比游标高效得多。
实际场景中的选择原则与注意事项
决定是否使用游标时，可以先问三个问题：一是有没有集合操作的等价写法；二是目标行数有多大；三是处理逻辑是否强依赖顺序或需要和外部资源交互。如果数据量较小，游标代码的可读性可能更高，但一旦进入生产环境且数据增长，游标的性能劣势就会被迅速放大。
在某些情况下游标仍然合理。例如需要依次执行存储过程、打印报表、发送邮件或调用外部程序，而参数来自某个查询结果。此时集合语句无法直接调用外部过程，游标可以提供清晰的执行顺序。对于这类少量行的循环任务，游标的绝对开销通常可以接受。
另外，可以用 WHILE 循环配合 TOP 1 和临时表来模拟游标，但这种方式未必比游标更快，反而可能因为多次扫描临时表而增加 I/O。窗口函数和递归 CTE 是更推荐的替代品。无论采用哪种方案，都应该用 SET STATISTICS TIME、IO 以及执行计划来验证实际开销，而不是仅凭代码长短判断。
最后需要提醒一点，游标声明中的 SELECT 语句如果包含 ORDER BY，应该明确游标类型是否允许排序。某些游标类型会忽略 ORDER BY 或产生不必要的排序操作，影响结果集的遍历顺序。对于只读逐行处理，优先使用 LOCAL FORWARD_ONLY STATIC READ_ONLY 的游标，并确保完成 CLOSE 和 DEALLOCATE。
SQL Server结果集游标修改时间：2026-10-01 09:59:38