游标是性能毒药，因其逐行处理违背数据库集合理论，每次FETCH触发上下文切换、锁申请和日志写入，而集合操作可并行、复用执行计划、走索引跳过数据。
SQL 存储过程里用游标慢，不是游标本身“写得不好”，而是它天然违背数据库最高效的执行模式——集合理论。直接说结论：绝大多数场景下，游标是性能毒药，能不用就别用；必须用时，也得严格控制范围和生命周期。
为什么游标比SET操作慢一个数量级？
数据库引擎（如 SQL Server、Oracle）的查询优化器专为批量数据设计，执行计划能并行、能复用、能走索引跳过大量数据。而游标强制把集合操作拆成单行循环：
- 每次
FETCH都是一次独立的逻辑读，触发一次上下文切换和锁申请 - 事务日志逐行写入，
UPDATE1000 行 = 1000 条日志记录，而非 1 条 - 无法利用
WHERE+ 索引快速定位，尤其当游标基于未索引字段或复杂表达式时 -
OPEN游标时，整个结果集可能已加载进内存（取决于游标类型），但后续每行处理仍需解析、赋值、判断、跳转
哪些游标写法会让性能雪上加霜？
常见错误不是“用了游标”，而是用错了方式。以下写法几乎必然拖垮性能：
- 在游标循环体内执行另一条
SELECT或UPDATE（俗称“嵌套游标”），形成 N×M 级扫描 - 游标定义里包含
JOIN多张大表，且关联字段无索引 → 先全表扫描再生成结果集 - 用
WHERE子句中对字段做函数操作，例如WHERE YEAR(OrderDate) = 2024→ 索引失效，游标底层结果集变慢 - 声明为
STATIC或KEYSET游标却只读取前几行，白白占用临时空间和内存 - 忘记
CLOSE和DEALLOCATE，导致会话级资源泄漏，累积后影响并发
有没有真需要游标的场景？
有，但非常窄。游标不可替代的点只在「必须逐行决策且依赖前序结果」时才成立，比如：
- 银行流水逐笔冲销，每笔更新都依赖上一笔的余额状态
- ETL 中某字段需调用外部 Web API 校验，且 API 有频控或状态依赖
- 生成带序号的报表，序号需按业务规则动态计算（非
ROW_NUMBER()能覆盖）
即便如此，也要优先考虑：WHILE + TOP 1 + ORDER BY + OFFSET/FETCH 替代传统游标；或把逻辑下沉到应用层分页处理。
替代游标的实际方案怎么选？
95% 的游标需求都能被更高效的方式替代，关键看数据特征和操作类型：
- 单纯遍历更新？→ 直接
UPDATE ... FROM或MERGE，例如：UPDATE t SET status = 'done' FROM orders t INNER JOIN #batch_ids b ON t.id = b.id - 需要按顺序处理并生成中间状态？→ 用
CTE+ROW_NUMBER()+ 窗口函数，避免显式循环 - 要逐行插入并返回新生成的
id？→OUTPUT子句，例如：INSERT INTO log(...) OUTPUT inserted.id SELECT ... FROM source - 跨库/跨服务协调？→ 放到应用层用流式读取（如
SqlDataReader.Read()），数据库只负责吐数据
真正难的是识别“看似必须用游标”的逻辑里，哪部分其实是可向量化、可下推、可缓存的。这种判断比写游标本身更耗时间，但也正是性能优化的起点。
