嵌套游标在绝大多数业务场景下不该存在，它几乎必然导致性能崩盘；真需要多层遍历逻辑，应优先用 join + 索引 或 cte + row_number() 分批替代。
直接说结论：嵌套游标在绝大多数业务场景下不该存在，它几乎必然导致性能崩盘；真需要多层遍历逻辑，优先用 JOIN + 索引 或 CTE + ROW_NUMBER() 分批替代，而不是设计“游标套游标”。
为什么嵌套游标是危险信号
一旦看到 DECLARE outer_cursor CURSOR 里又嵌了 DECLARE inner_cursor CURSOR，基本可以判定这个存储过程已经脱离数据库集合运算的本质。每打开一个游标，就多一份 TempDB 开销、一次查询计划编译、一套锁资源申请；而嵌套后，内层游标会在外层每 FETCH 一行时重复执行——如果外层返回 1000 行，内层 SELECT 就被跑 1000 遍，不是“查一次”，是“查一千次”。
常见错误现象包括：wait_type = PAGEIOLATCH_SH（磁盘 I/O 等待）、sys.dm_exec_requests 显示长时间 status = suspended、执行计划中出现大量红色警告“Table Scan”或“Key Lookup”。
- MySQL 5.7+ 会尝试物化内层游标查询，但若没加索引提示（如
/*+ USE_INDEX(t2, idx_pid) */），仍可能全表扫描 - SQL Server 中嵌套游标默认是 KEYSET 类型，会为每一行维护键集快照，内存和 TempDB 压力陡增
- Oracle 的 PL/SQL 虽支持
CURSOR FOR LOOP嵌套，但执行计划缓存容易固化低效路径，参数变化后无法自动重编译
嵌套逻辑的等价 JOIN 写法（以三层 IN 为例）
原游标嵌套结构常对应这类语义：“查出 A 表中满足条件的记录，对每条记录，再查 B 表关联数据，再对每个 B 记录查 C 表状态”。这本质是三表关联，不是三层循环。
错误写法（游标嵌套）：
DECLARE @a_id INT
DECLARE a_cur CURSOR FOR SELECT id FROM a WHERE status = 'active'
OPEN a_cur
FETCH NEXT FROM a_cur INTO @a_id
WHILE @@FETCH_STATUS = 0
BEGIN
DECLARE @b_id INT
DECLARE b_cur CURSOR FOR SELECT id FROM b WHERE a_id = @a_id
OPEN b_cur
FETCH NEXT FROM b_cur INTO @b_id
WHILE @@FETCH_STATUS = 0
BEGIN
UPDATE c SET processed = 1 WHERE b_id = @b_id
FETCH NEXT FROM b_cur INTO @b_id
END
CLOSE b_cur
DEALLOCATE b_cur
FETCH NEXT FROM a_cur INTO @a_id
END
正确替换为单条 JOIN 更新：
UPDATE c SET processed = 1 FROM c INNER JOIN b ON c.b_id = b.id INNER JOIN a ON b.a_id = a.id WHERE a.status = 'active'
- 必须确保
b.a_id和c.b_id上有索引，否则 JOIN 退化为嵌套循环（NL）且无驱动表优势 - 若
a表过滤后仍很大，考虑先用SELECT a.id INTO #a_ids FROM a WHERE status = 'active'建临时表并加主键，再 JOIN，避免重复计算 - 注意 NULL 安全性：JOIN 自动跳过 NULL，而原游标逻辑若依赖
IS NULL判断，需额外补OR a.id IS NULL条件验证
实在绕不开逐行处理时的轻量替代方案
仅当业务逻辑含副作用（如调外部 API、发邮件、写文件日志）且无法批量聚合时，才考虑保留“类循环”结构。此时必须避开游标，改用可控分批：
- 用
CTE + ROW_NUMBER()打序号，再WHERE rn BETWEEN @start AND @end分片，每次处理 5000 行。ORDER BY 字段必须有索引，否则ROW_NUMBER()强制 SORT - 用临时表
#work_items存主键集，再WHILE (EXISTS (SELECT 1 FROM #work_items))+DELETE TOP (1000) FROM #work_items OUTPUT DELETED.id INTO #batch，保证每批只读一次源表 - 显式加
SET XACT_ABORT ON，防止某批失败后事务挂起，阻塞后续批次 - 绝对不要在循环体内反复查原表——所有依赖字段（如 name、email、amount）必须在插入
#work_items时一并SELECT INTO进来
最易被忽略的一点：嵌套游标的问题往往不在于“怎么写得更快”，而在于“为什么认定必须嵌套”。多数时候，那个“内层要根据外层某字段查一遍”的需求，其实可以通过预聚合、中间状态表或应用层缓存提前化解——数据库不是万能循环引擎，别把它当脚本语言用。
