WHILE循环需配合SET/SELECT手动模拟游标，通过自增序号+计数器逐行处理；必须更新计数器、避免循环中修改原表、大数据量时注意ROW_NUMBER()性能及索引优化。
WHILE 循环必须配合 SET 和 SELECT 才能读取临时表行
SQL Server 的 WHILE 本身不支持“遍历结果集”，它只判断布尔条件。想逐行处理临时表，得手动维护一个游标式变量（比如 ID 或序号），再用 SELECT 按该变量查单行数据。常见错误是直接写 WHILE EXISTS(SELECT ...) 却没更新变量，导致死循环或只处理第一行。
实操建议：
- 先给临时表加自增序号列（如
IDENTITY(1,1)或用ROW_NUMBER()），避免依赖原表主键是否连续 - 用
SET @i = 1初始化计数器，SELECT @total = COUNT(*) FROM #temp获取总行数 - 循环体里必须用
SELECT @col1 = col1, @col2 = col2 FROM #temp WHERE rn = @i提取当前行——不能省略WHERE条件 - 每次循环末尾必须
SET @i = @i + 1，否则条件永远为真
临时表没索引时 ROW_NUMBER() 性能会明显下降
如果临时表数据量超过 5000 行，又没建索引，用 ROW_NUMBER() OVER (ORDER BY ...) 生成序号可能拖慢整个存储过程。尤其当 ORDER BY 字段未索引、或用了表达式（如 ORDER BY UPPER(name)），SQL Server 会强制排序，CPU 和 tempdb 压力都会上升。
实操建议：
- 建临时表后立即加索引：
CREATE CLUSTERED INDEX IX_temp_rn ON #temp(rn) - 若原始数据已有唯一标识字段（如
id），优先用它做循环依据，避免额外计算ROW_NUMBER() - 确认
ORDER BY字段在源表中已存在索引，且类型匹配（比如不要对varchar排序却用nvarchar变量比较）
WHILE 循环里修改同一临时表容易触发“结果集变更”逻辑错乱
在循环体内执行 UPDATE #temp 或 DELETE FROM #temp 后，如果继续用 @i 递增去查下一行，很可能跳过被删/改的行，或查到空值——因为行物理位置和序号映射关系已被破坏。
实操建议：
- 避免在循环中增删临时表数据；如必须修改，改用
TOP 1+ORDER BY查最小未处理 ID，再DELETE或UPDATE，然后重新计数 - 更稳妥的做法是把待处理的 ID 先存进另一个临时表（如
#todo），循环只读#todo，处理逻辑作用于原表 - 若需逐行插入新数据，别在
WHILE里反复INSERT INTO #temp，应先拼好所有值，最后一次性INSERT ... SELECT
替代方案：用 CURSOR 虽然慢但语义更清晰
很多人回避 CURSOR 是因为听说它性能差，但对小数据量（DECLARE cur CURSOR FOR SELECT ... 反而比手写 WHILE 更少出错。SQL Server 对静态游标做了不少优化，实际开销未必比嵌套子查询高。
实操建议：
- 用
LOCAL FAST_FORWARD READ_ONLY定义游标，禁用更新能力，减少锁和内存占用 - 务必配对使用
OPEN/FETCH/CLOSE/DEALLOCATE，漏掉DEALLOCATE会导致游标句柄残留 - FETCH 失败时检查
@@FETCH_STATUS是否为 0，不是就跳出循环——这是最常被忽略的退出条件
临时表循环真正难的不是语法，而是状态同步：序号、数据变动、退出边界这三者稍有脱节，结果就不可控。哪怕只是加个 PRINT @i 调试，也建议放在 FETCH 或 SELECT 之后、业务逻辑之前。
