游标更新前应优先用UPDATE FROM或MERGE替代；必须用时选FAST_FORWARD类型并加TYPE_WARNING；循环内避免额外IO，JOIN预取关联字段；每100–500行显式COMMIT；CLOSE后必须DEALLOCATE。
游标更新前先确认：真需要逐行吗？
90% 的所谓“必须用游标更新”场景，其实能用一条 UPDATE FROM 或 MERGE 解决。比如按部门批量调薪、按状态批量修正时间戳——这些逻辑不依赖前一行结果，也不调外部服务，就别碰游标。硬上只会让几万行更新从 0.5 秒拖到 40 秒，还锁表。
@@FETCH_STATUS = 0 不是万能终止条件，它只表示上一次 FETCH 成功，但不保证还有下一行；漏写 FETCH 或放错位置（比如写在循环末尾却忘了第一次 FETCH），就会无限循环或跳过首行。
真正绕不开游标的典型场景只有这几个：
- 每行要调一次
EXEC sp_send_dbmail发通知 - 更新前需查另一库的实时接口返回值（如风控评分）
- 需按分组内顺序计算滚动累计值，且窗口函数无法覆盖（比如动态阈值触发）
- 上游系统强制要求逐条返回处理状态码
声明和打开阶段：选对类型，显式控制资源
SQL Server 默认游标是 DECLARE ... SCROLL CURSOR，它支持任意定位但开销极大。生产环境请直接用 FAST_FORWARD —— 它等价于 FORWARD_ONLY READ_ONLY，内存占用低、初始化快、锁粒度小。
必须加 TYPE_WARNING 选项：
DECLARE cur CURSOR FAST_FORWARD TYPE_WARNING FOR SELECT id, amount FROM orders WHERE status = 'pending'这样一旦 SQL Server 因内存不足或查询复杂度降级为静态游标，会抛出警告，而不是静默变慢。
OPEN 前确保 WHERE 条件已走索引。如果游标查询本身执行计划是 type = ALL（全表扫描），后面所有优化都白搭。用 EXPLAIN 或 SSMS 的“显示实际执行计划”验证。
循环体内：砍掉所有额外 IO，控制提交节奏
游标慢，70% 出在循环体里反复查表。比如：
FETCH NEXT FROM cur INTO @id, @amount; WHILE @@FETCH_STATUS = 0 BEGIN -- ❌ 错误：每次都要去查用户等级表 SELECT @level = level FROM users WHERE user_id = @id; <p>UPDATE orders SET processed_level = @level WHERE id = @id;</p><p>FETCH NEXT FROM cur INTO @id, @amount; END
正确做法是把关联字段提前 JOIN 进游标查询：
DECLARE cur CURSOR FAST_FORWARD TYPE_WARNING
FOR SELECT o.id, o.amount, u.level
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE o.status = 'pending'每处理 100–500 行后必须 COMMIT。不提交=事务日志持续增长+行锁不释放+阻塞其他会话。别依赖自动提交——T-SQL 默认是隐式事务模式，SET IMPLICIT_TRANSACTIONS OFF 要显式关掉。
收尾动作：CLOSE 和 DEALLOCATE 缺一不可
CLOSE cur 只释放游标结果集的内存，但游标定义还在；DEALLOCATE cur 才真正清空元数据和 tempdb 占用。存储过程中漏掉 DEALLOCATE，会导致后续调用时提示“游标已存在”，更糟的是 tempdb 空间缓慢泄漏。
容易被忽略的细节：
- 游标变量名不要和列名同名（如
DECLARE @id INT+SELECT id FROM ...），T-SQL 会优先绑定列名，导致变量始终为空 -
FETCH后立刻检查@@FETCH_STATUS，别等到循环体末尾才判断，否则最后一行会被重复处理一次 - 如果更新逻辑可能失败（如违反约束），在循环内加
TRY...CATCH，但别在 catch 里CONTINUE——错误行跳过会导致主键冲突或数据不一致
游标不是不能用，而是每一步都得卡准数据库的资源边界。真正卡死的从来不是语法，是没管住锁、日志、内存这三根线。
