游标在SQL中用于逐行处理结果集，但性能差，应避免在高并发或大数据场景使用；必须使用时需明确不可替代场景、选对类型并优化生命周期。
游标在 SQL 中主要用于逐行处理结果集，但它的性能通常较差，应尽量避免在高并发或大数据量场景中使用。真正需要游标时，关键在于理解其适用边界、合理选择类型，并配合底层优化手段。
何时必须用游标？明确不可替代的业务场景
游标不是“能不用就不用”的教条，而是“能用集合操作就别用游标”的实践原则。以下情况较难绕过游标：
- 需要调用外部系统（如发短信、写日志、调 API）且每行逻辑强依赖前一行状态
- 复杂分组内需按序计算累计值，窗口函数无法覆盖（例如动态阈值滚动求和）
- 存储过程中需根据当前行数据动态拼接并执行 DDL 或跨库语句
- 遗留系统改造受限，上游应用只能接收逐条处理反馈
选对游标类型：静态、键集、动态、只进——差异远不止速度
不同游标行为直接影响一致性、内存占用和锁粒度：
- STATIC：快照式，不反映源表变更，内存开销大但读一致性高，适合只读+小结果集
- KEYSET：仅缓存键值，支持部分更新感知，适合中等规模且需响应部分修改的场景
- DYNAMIC：实时反映所有增删改，锁竞争激烈，仅在极少数强实时需求下启用
- FAST_FORWARD（SQL Server）或 FORWARD_ONLY READ_ONLY（通用）：最轻量，无游标键维护，推荐作为默认起点
性能硬核优化：从声明到释放的 5 个关键控制点
游标慢，往往不是因为“用了游标”，而是因为没控住资源生命周期：
- 显式指定 TYPE_WARNING 选项，让 SQL Server 在降级游标类型时抛出警告，避免静默变慢
- 用 FETCH ABSOLUTE n 或 FETCH PRIOR 前确认游标支持定位，否则触发全扫描重建
- 在循环体内避免嵌套 SELECT 或 UPDATE —— 提前把关联字段 JOIN 到游标查询中，减少每次 FETCH 后的额外 IO
- 批量提交：每处理 100–500 行显式 COMMIT，防止事务日志暴涨；禁用自动提交模式（SET IMPLICIT_TRANSACTIONS OFF）
- 游标用完立刻 CLOSE + DEALLOCATE，尤其在存储过程中，未释放会持续占用 tempdb 和内存
替代方案优先级清单：90% 的游标需求其实可绕过
在写游标前，快速过一遍这些更高效的选择：
- CTE + 窗口函数：累计、排名、分组内排序取 Top N，基本覆盖 60% 的“逐行计算”需求
- UPDATE ... FROM / MERGE：多表关联更新，比游标 UPDATE 快 5–20 倍，且原子性更好
- 临时表 + WHILE 循环：用主键 ID 分页驱动（WHERE id > @last_id），规避游标开销，便于监控进度
- 应用层流式处理：用 JDBC/ODBC 的 fetchSize 或 .NET 的 SqlDataReader.Read() 边取边处理，数据库只负责吐数据
游标不是反模式，而是特定场景下的精密工具。用得准，它能解决集合操作难以表达的逻辑；用得滥，它会成为性能瓶颈的放大器。核心不在语法多炫，而在清楚知道“为什么非它不可”以及“怎么让它少喘气”。
