游标不是处理子查询结果集的推荐方式，除非子查询逻辑本身无法集合化——比如每行要调用标量函数、需依赖上一行状态、或必须记录逐行错误上下文。
游标不是处理子查询结果集的推荐方式，除非子查询逻辑本身无法集合化——比如每行要调用标量函数、需依赖上一行状态、或必须记录逐行错误上下文。直接把子查询塞进游标声明里，性能差、锁表风险高、还容易漏第一行。
为什么不能直接把子查询当游标源？
子查询若含聚合、窗口函数、或引用外部变量（如 @input_id），在 DECLARE CURSOR FOR 中可能被提前求值或报错；更常见的是，SQL Server 会把整个子查询结果固化为静态快照，后续数据变更不可见，而你本意可能是想“边查边校验”。另外，子查询若没明确排序（ORDER BY），游标遍历顺序不确定，导致校验逻辑不可重现。
常见错误现象：Invalid column name（子查询里用了未定义别名）、Cursorfetch: The number of variables must match the number of columns（子查询列数和 INTO 变量不一致）、或 @@FETCH_STATUS 第一次就为 -1（子查询无结果，但你没检查就进循环）。
正确写法：先存到临时表，再声明游标
把子查询结果落地为 #temp 或 @table_var，能显式控制数据形态、加索引、补 ORDER BY，也避免重复执行子查询。
- 万级以内数据优先用
DECLARE @t TABLE(...)，内存操作快，无需CREATE INDEX - 十万级以上务必用
SELECT ... INTO #temp，并在关键列（如主键、校验字段）上CREATE CLUSTERED INDEX - 子查询含
TOP或OFFSET-FETCH时，必须带ORDER BY，否则 SQL Server 拒绝创建游标 - 临时表字段类型要显式声明，别依赖子查询推导——比如子查询
CONVERT(VARCHAR, dt)返回长度不定，临时表里得写成VARCHAR(32)
示例骨架：
SELECT id, email, ISNULL(phone, '') AS phone INTO #check_list FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'pending') ORDER BY id; DECLARE cur CURSOR LOCAL FAST_FORWARD FOR SELECT id, email, phone FROM #check_list;
FETCH 和 WHILE 循环里的关键动作
子查询结果已落库，游标只是读取器，重点在循环体内怎么安全取值、判空、续跑。
-
FETCH NEXT FROM cur INTO @id, @email, @phone后必须立刻检查@@FETCH_STATUS，不能塞进WHILE条件——否则空结果集时循环直接跳过 - 所有变量必须预先
DECLARE，且类型宽度 ≥ 临时表对应列（@email VARCHAR(255)要 ≥#check_list.email的定义） - 校验失败时别用
RAISERROR中断，改用INSERT INTO log_table记录@id,@email,ERROR_MESSAGE()，然后CONTINUE - 循环末尾只写一次
FETCH NEXT，不要在循环体中间再OPEN或FETCH PRIOR——游标是单向的，FAST_FORWARD不支持回溯
比游标更优的替代路径
90% 的“子查询+逐行处理”需求，其实能用集合操作重写，快一个数量级，还不锁表。
- 纯校验类（如邮箱格式、手机号长度）：用
SELECT ... WHERE NOT dbo.IsValidEmail(email)一次性捞出问题行 - 需调用标量函数但函数可改写：把它内联为
CASE WHEN CHARINDEX('@', email) = 0 THEN 'invalid'... - 要生成日志或中间表：用
INSERT INTO log SELECT id, email, 'valid' FROM #check_list WHERE ...，而非循环插入 - 真需要状态传递（如“上一行失败则跳过当前行”）：改用
ROW_NUMBER()+ 自连接或递归 CTE，比游标稳定
真正绕不开游标的时候，往往是你已经确认子查询结果集小（
