游标导致执行时间暴增的底层原因是将集合操作强行拆解为单行循环，每次FETCH触发上下文切换、锁检查和内存寻址，10万行即10万次独立执行路径；而集合操作由优化器一次性生成高效计划，可走索引扫描或并行连接。
游标导致执行时间暴增的底层原因
游标把集合操作强行拆成单行循环，每次 FETCH 都触发一次查询上下文切换、一次锁检查、一次内存寻址。10 万行数据 = 至少 10 万次独立执行路径，而集合操作（如 UPDATE ... WHERE）由优化器一次性生成高效执行计划，走索引扫描或并行哈希连接即可完成。
常见错误现象：某日结任务用游标处理 80 万订单，耗时 32 分钟、CPU 持续 95%；改写为 UPDATE order_log SET status = 'processed' WHERE batch_id = @batch 后，800ms 完成。
- 每行
FETCH都可能重新评估锁粒度（行锁 → 页锁 → 表锁升级） - 游标结果集常驻内存，
DECLARE ... CURSOR FOR SELECT *容易触发隐式排序和临时表膨胀 -
@@FETCH_STATUS是全局变量，多游标嵌套时极易被覆盖，导致循环提前退出或死循环
并发场景下游标引发的锁与死锁风险
游标打开后，多数数据库（SQL Server / Oracle）默认持有结果集中的行锁或键范围锁，直到 CLOSE 或事务结束。这意味着一个长周期游标会持续阻塞其他会话对同一数据的修改。
使用场景：库存扣减存储过程中用游标逐条校验并更新，若两个事务同时打开相同商品 ID 的游标，极大概率因锁等待顺序不一致触发死锁 —— 错误信息类似 Deadlock encountered ... ROLLBACK requested by user。
-
FAST_FORWARD游标虽能减少部分开销，但无法规避锁持有时间长的问题 - 即使加了
READ_ONLY，某些引擎仍会对扫描过的页面加意向锁 - 显式事务中未及时
CLOSE+DEALLOCATE，会导致连接池中连接长期占用资源
替代游标的三种可靠集合操作模式
95% 的游标逻辑都能用以下方式无损替换，且语义更清晰、性能提升通常在 10 倍以上。
Agents 正在你的整个代码库中处理越来越复杂、运行时间更长的任务。本次版本引入了新的 agent 框架改进，以实现更好的上下文管理，并在编辑器和 CLI 中带来了许多提升使用体验的修复。
—— 简单条件更新：直接用 UPDATE ... FROM 或子查询
UPDATE t1 SET t1.flag = 1 FROM sales t1 INNER JOIN customers t2 ON t1.cust_id = t2.id WHERE t2.level = 'VIP';
—— 复杂中间计算：用 CTE 或临时表预聚合，再关联更新
WITH top_orders AS ( SELECT cust_id, SUM(amount) amt FROM orders GROUP BY cust_id HAVING SUM(amount) > 10000 ) UPDATE c SET is_premium = 1 FROM customers c INNER JOIN top_orders o ON c.id = o.cust_id;
- 避免在游标循环里调用标量函数（如
dbo.CalculateTax(@amt)），改用内联表值函数或直接写表达式 - 批量分页处理大表时，用
OFFSET-FETCH或WHERE id > @last_id分段，而非游标遍历 - 真需要逐行逻辑（如调用外部 API），也应把数据导出到应用层处理，而非在数据库内硬扛
什么情况下不得不保留游标？以及必须遵守的底线
仅当满足全部以下条件时，才考虑游标：① 必须依赖上一行计算结果（如滚动累计、状态机跳转）；② 数据量稳定 ≤ 5000 行；③ 执行频次极低（如每日一次的报表归档）。
此时务必做到：
- 声明时明确指定
LOCAL FAST_FORWARD READ_ONLY，禁用动态游标 - 在
BEGIN TRY内打开，在BEGIN CATCH中强制CLOSE+DEALLOCATE - 用
SET ROWCOUNT或TOP限制结果集大小，防止意外加载全表
真正容易被忽略的点是：游标不是“慢一点”，而是把数据库从集合处理器降级为记录模拟器 —— 这种范式错位，会在数据量翻倍、并发增加、索引失效等任意一个变量变化时，让性能断崖式恶化。
