WHILE循环比游标更轻量，因其无需声明、打开、提取、关闭四步流程，不维护游标状态和结果集快照，内存开销小、执行路径直接；适用于简单逐行处理，但需自行管理驱动键以防漏行、重复或死循环。
WHILE 循环在存储过程中为什么比游标更轻量
因为 WHILE 不需要声明、打开、提取、关闭四步流程，也不维护游标状态和结果集快照，内存开销小，执行路径更直接。尤其在只做简单逐行处理（如批量更新某字段、生成日志记录）时，WHILE 配合临时表或变量就能完成，避免了游标隐式锁表、阻塞并发读的问题。
但注意：WHILE 本身不提供“当前行”抽象，你需要自己管理索引或主键值，否则容易漏行、重复或死循环。
用临时表 + WHILE 实现安全的逐行处理
典型场景：对 orders 表中所有未发货订单更新 status 并记录操作时间。不能直接 UPDATE？比如要调用外部逻辑、写审计日志、或每行处理耗时差异大需控制节奏。
- 先建带主键/唯一标识的临时表：
SELECT order_id, customer_id INTO #order_batch FROM orders WHERE status = 'pending' - 用
MIN(order_id)或自增row_number()做驱动键，避免依赖物理顺序 - 循环体里必须有明确的退出条件，且每次迭代后要推进驱动键：
SET @current_id = (SELECT MIN(order_id) FROM #order_batch WHERE order_id > @current_id) - 每次只查一行（
WHERE order_id = @current_id），处理完再删或标记，防止重复处理
WHILE 循环常见死循环陷阱
最常出问题的是驱动变量没更新、或更新后仍满足循环条件。例如：
DECLARE @i INT = 1;
WHILE @i <= 10
BEGIN
-- 忘了写 SET @i = @i + 1;
PRINT @i;
END这种会无限打印 1。其他高危情况包括：
- 在循环内执行
DELETE或UPDATE影响了驱动查询的结果集，导致@current_id查不到下一条 - 用
TOP 1+ORDER BY取下一行，但排序字段存在重复值，WHERE id > @last_id跳过部分记录 - 临时表被意外截断（
TRUNCATE TABLE #tmp）或作用域失效（如在嵌套存储过程中创建）
性能对比：WHILE vs 游标，什么时候该换回来
单次处理逻辑极简单（如仅赋值+插入）且数据量 WHILE 通常快 2–5 倍；但一旦涉及多表 JOIN、子查询、或频繁调用函数，WHILE 的逐行开销会迅速反超。这时候游标的隐式批处理优化反而更稳。
更关键的分水岭是事务控制粒度：如果每行都需独立 TRY...CATCH 和 ROLLBACK，WHILE 写起来冗长易错；而游标配合 FETCH STATUS 更易捕获单行失败。别为了“不用游标”硬扛——SQL Server 对静态游标做了大量底层优化，不是洪水猛兽。
真正该警惕的不是游标本身，而是没加 TYPE_WARNING 提示就用了动态游标，或者在循环里反复 EXEC 字符串拼接的 SQL。
