嵌套游标是高危模式，导致执行时间指数增长、死锁陡增、调试失效；95%场景可用cte+标量函数+批量update替代，语义更清、性能更稳。
嵌套游标不是性能问题的“可选项”，而是直接触发执行时间指数级增长、死锁概率陡增、调试完全失效的高危模式——95% 的业务逻辑都能用 CTE + 标量函数 + 批量 UPDATE 替代，且语义更清晰、执行计划更稳定。
嵌套游标会让执行时间从秒级跳到分钟级
外层游标每 FETCH 一行，内层游标就重新打开、扫描、关闭一次。1000 行外层 × 100 行内层 = 至少 10 万次独立查询执行路径。每次 FETCH 都触发上下文切换、锁检查、内存寻址和执行计划重编译（尤其当参数类型不匹配时）。某订单分摊过程用双层游标处理 5 万主单+平均 8 子单，耗时 27 分钟；改写为 MERGE + CTE 后，830ms 完成。
- SQL Server 中
DECLARE CURSOR FOR SELECT *默认隐式排序，可能触发 TempDB 溢出 - 内层游标若含
WHERE parent_id = @outer_id，而@outer_id是VARCHAR类型但字段是INT，将导致全表扫描 -
@@FETCH_STATUS是全局变量，嵌套中任意一层未正确判断状态，就会让外层循环提前退出或陷入死循环
嵌套游标极易引发不可复现的死锁
游标默认持有键范围锁（Key-Range Lock），直到 CLOSE 或事务结束。嵌套结构天然导致锁获取顺序混乱：A 过程先锁 orders 再进内层游标锁 order_items，B 过程反向操作，两事务稍有并发即报 Deadlock encountered — ROLLBACK requested by user。这种死锁在低并发测试中几乎不出现，上线后却高频发生。
- 即使加了
READ_ONLY，SQL Server 仍会对扫描过的索引页加意向锁（Intent Lock） - 内层游标反复
OPEN/CLOSE会持续申请/释放锁资源，放大争用窗口 - 无法通过
SET DEADLOCK_PRIORITY缓解——锁序由游标声明顺序决定，不是语句执行顺序
调试和维护成本远超预期
你无法对嵌套游标中某一行的转换结果做断点或日志：PRINT 只能输出字符串，不能捕获中间计算值；临时表写入又引入额外 I/O 和事务膨胀。更麻烦的是，一旦逻辑要加新字段或改条件，就得同时修改两层游标声明、两处 FETCH、三段 WHERE，漏掉任何一处就静默失败。
- 嵌套游标内调用
CAST、CASE、跨表 JOIN，等于把本可一次完成的计算重复执行 N×M 次 - 所有临时表必须显式加主键（如
id INT PRIMARY KEY），否则优化器放弃哈希匹配，退化为嵌套循环 - 标量函数（如
dbo.fn_score_level）可封装确定性转换逻辑，被SELECT、UPDATE、游标变量赋值统一调用，避免重复解析
真正难的不是写出嵌套游标，而是让它在 10 万行数据、5 并发、跨凌晨批处理场景下不出错。多数“必须用嵌套”的需求，本质是没把“取数 → 计算 → 写入”三层逻辑拆开固化——先落盘再处理，比在游标里硬扛强十倍。
