嵌套游标不是数据转换的首选方案，它易致性能坍塌和维护黑洞；应将转换逻辑抽出，用集合操作或标量函数实现，如用dbo.fn_score_level封装等级转换，避免循环内重复计算与隐式转换。
游标嵌套不是数据转换的首选方案，它容易引发性能坍塌和维护黑洞；真正需要的是把转换逻辑从循环体内抽出来，用集合操作或标量函数承载。
为什么嵌套游标在转换场景中特别危险
当你在嵌套游标里做数据转换（比如把 @score 转成等级、拼接描述、调用 CAST 或 CASE），实际是在每行上重复解析同一段逻辑。SQL Server 每次 FETCH 都可能触发隐式类型转换、重复计算、甚至跨表 JOIN —— 这些本可一次完成的事，被拆成 N×M 次执行。
- 常见错误现象：
UPDATE语句卡在嵌套游标循环里，logical reads翻 10 倍，而等价的MERGE+CTE版本 200ms 完成 - 调试困难：你无法对游标内某一行的转换结果打日志，除非手动加
PRINT或临时表写入，但那又引入额外 I/O - 事务膨胀：外层游标未提交时，内层游标反复打开/关闭，锁资源持续占用，极易阻塞其他会话
替代方案：用标量函数封装转换逻辑
把“状态码转中文”“金额四舍五入并补零”这类确定性转换，定义为数据库内的标量函数，让游标（如果非用不可）只负责调度，不负责计算。
- SQL Server 示例：
CREATE FUNCTION dbo.fn_score_level (@score INT) RETURNS VARCHAR(10) AS BEGIN RETURN CASE WHEN @score IS NULL THEN 'N/A' WHEN @score >= 90 THEN 'A' WHEN @score >= 80 THEN 'B' ELSE 'C' END END - 调用方式统一：
SELECT dbo.fn_score_level(t.score) FROM source_table t，无论在 SELECT、UPDATE 还是游标变量赋值中都可复用 - 避免陷阱：函数内不要调用表、不要含
GETDATE()等非确定性函数，否则会导致执行计划缓存失效或并行度下降
如果必须用嵌套游标，至少保证三层隔离
把“取数 → 转换 → 写入”彻底拆开，禁止在 FETCH 后直接 UPDATE 或 INSERT。哪怕只是临时表，也要先落盘再处理。
- 第一步：用
SELECT ... INTO #temp_outer把外层主键集固化，避免游标期间基表变更干扰 - 第二步：对每个外层 ID，用
INSERT INTO #temp_inner SELECT ... WHERE parent_id = @outer_id批量拉取子集，而非声明新游标 - 第三步：对
#temp_inner执行一次UPDATE #temp_inner SET converted = dbo.fn_xxx(raw)，再统一回写目标表 - 关键细节：所有临时表必须显式加主键（如
id INT PRIMARY KEY），否则 SQL Server 优化器可能放弃哈希匹配，退化为嵌套循环
最常被忽略的一点：嵌套游标本身不报错，但它会让 STATISTICS IO 显示的逻辑读远低于真实开销——因为 TempDB 中的游标快照、版本存储、锁等待时间不会计入常规统计。上线前务必用 SET STATISTICS XML ON 看实际执行计划里的 “Cursor Implicit Conversion” 和 “Worktable” 节点大小。
