while循环不能直接逐行处理结果集，需先获取主键再按序取值模拟游标；适合小数据量批量操作，而真正顺序执行副作用应使用fast_forward游标。
WHILE循环本身不能直接“逐行处理结果集”
很多人误以为 WHILE 能像游标那样自动遍历查询结果，其实它只是基于变量条件重复执行代码块。真正实现“逐行处理数据”的核心是：先用 SELECT 获取主键或唯一标识（如 ID），再用 WHILE 按 ID 顺序取值、查出对应行、处理、推进。这种方式本质是“模拟游标”，但更轻量、无资源泄漏风险。
- 适合数据量小（
- 必须有可排序且连续/稀疏可控的数值型主键，否则容易漏行或死循环
-
MIN(ID)和MAX(ID)要在循环前一次性算好，避免每次SELECT MIN带来性能抖动 - 如果表被并发修改（如新增/删除行），该方式可能跳过新插入行或重复处理已删行
标准游标 + WHILE 的最小可靠骨架
这才是 SQL Server 中真正“逐行处理结果集”的标准做法。关键不是语法多炫，而是生命周期控制不出错。
- 必须声明
LOCAL FAST_FORWARD游标：减少锁开销，禁止反向 FETCH -
OPEN后立刻FETCH NEXT，否则@@FETCH_STATUS是未定义值 -
WHILE @@FETCH_STATUS = 0是唯一安全判断，别用= -1或!= 0 - 循环体末尾必须再次
FETCH NEXT，否则会无限处理同一行 -
CLOSE和DEALLOCATE缺一不可；只CLOSE不DEALLOCATE会导致后续同名游标报错
DECLARE @id INT, @name NVARCHAR(50); DECLARE cur CURSOR LOCAL FAST_FORWARD FOR SELECT ID, Name FROM Users WHERE Status = 'Pending'; <p>OPEN cur; FETCH NEXT FROM cur INTO @id, @name;</p><p>WHILE @@FETCH_STATUS = 0 BEGIN -- 处理单行：比如发通知、更新状态 UPDATE Users SET Status = 'Processed' WHERE ID = @id;</p><p>FETCH NEXT FROM cur INTO @id, @name; -- 这行不能少 END</p><p>CLOSE cur; DEALLOCATE cur;</p>
为什么游标常比 WHILE + ID 查询还慢？
游标慢不是因为“逐行”这个动作本身，而是默认行为太重：它默认支持滚动、更新定位、事务回滚点保存。你在 SSMS 里跑几百万行游标卡住，大概率是因为没加 LOCAL FAST_FORWARD，或者在循环里嵌套了低效子查询。
-
FAST_FORWARD游标底层等价于只进只读的 API 游标，性能接近集合操作 - 避免在循环体内执行
SELECT COUNT(*)或未走索引的UPDATE - 如果只是做简单字段转换（如截取
SUBSTRING(sort, 1, 2)），优先改用集合更新：UPDATE t SET priority = SUBSTRING(sort, 1, 2) - 游标真正的不可替代场景：某行处理逻辑依赖上一行输出、需调用外部存储过程、或必须按严格顺序触发副作用（如发短信）
字符串截取配合循环时最容易踩的坑
当你要在循环中拆解类似 'P01_202409281030' 这种字段，SUBSTRING、CHARINDEX 组合极易出错，尤其在分隔符缺失时。
-
SUBSTRING(str, start, length)的start从 1 开始，不是 0 —— 写惯 Python/JS 的人常在这里翻车 -
CHARINDEX('_', str)找不到下划线时返回 0，若直接用于SUBSTRING(str, 1, CHARINDEX('_', str)-1)，长度变成 -1，语句直接报错 - 正确写法是加
CASE WHEN CHARINDEX('_', str) > 0 THEN ... ELSE str END - 如果字段含空格或 NULL，
LEN()和DATALENGTH()行为不同，建议统一用ISNULL(RTRIM(str), '')预处理
游标和 WHILE 的边界其实很清晰：需要真正按结果集顺序逐行执行副作用，就老实用带 FAST_FORWARD 的游标；只是想批量生成或补数，用纯 WHILE 控制计数器更干净。最危险的是半吊子写法——既没游标的严谨性，又缺集合操作的效率。
