SQL 游标（cursor）的使用边界与 set-based 思维的强制转换实践

游标被dba否决主因是违背set-based原则，强行row-by-row处理导致性能与并发问题；仅极少数场景（如调用外部api、无法用窗口函数的滚动计算）才需使用，其余应优先用cte、窗口函数或join替代。

游标为什么总被 DBA 一票否决

因为绝大多数用游标的地方，本质是没想清楚数据该“怎么动”——游标把 set-based 操作硬掰成 row-by-row，CPU、锁、日志全涨一截，还容易出并发问题。DECLARE CURSOR 不是语法错，是设计信号灯：这里逻辑可能已经掉进过程式陷阱了。

常见错误现象：Cursor fetch returned 0 rows 却还在循环里做 UPDATE；游标嵌套三层后执行超时；同一张表在游标中 select 又在循环里 UPDATE，触发阻塞或死锁。

使用场景极窄：必须逐行调用外部 API（如发短信）、需要依赖前一行计算结果（如滚动累计但窗口函数不适用）、或处理无法建模为集合的异构数据流。除此之外，先写个 SELECT 看看能不能覆盖需求。

用 CTE + 窗口函数替代简单游标循环

比如按时间顺序给用户行为打序号、算间隔、取上一条记录——这些根本不需要游标。ROW_NUMBER()、LAG()、LEAD() 在 postgresql / SQL Server / oracle / mysql 8.0+ 都能直接干掉 90% 的“伪游标”逻辑。

实操建议：

• LAG(user_id) OVER (PARTITION BY session_id ORDER BY event_time) 比游标里存上一行变量更稳，且无状态残留风险
• 注意 PARTITION BY 和 ORDER BY 必须明确，否则 LAG 返回 NULL 不报错但结果错得隐蔽
• SQL Server 中 OFFSET-FETCH 分页比游标分页快一个数量级，且避免 FETCH NEXT 的隐式锁等待

性能影响：窗口函数走索引排序时，执行计划仍是单次扫描；游标默认触发多次 FETCH，每次可能回表、加锁、生成新执行计划。

真要游标？必须加 WITH SCROLL 和显式关闭

不加 WITH SCROLL 的游标在多数引擎里只支持单向遍历，一旦 FETCH PRIOR 就报错；更关键的是，没 CLOSE 和 DEALLOCATE 的游标会一直占着连接资源，尤其在存储过程中反复调用时，很快耗尽 max_connections。

实操建议：

• PostgreSQL 中用 MOVE FORWARD 10 跳过中间行比循环 FETCH 10 次高效得多
• SQL Server 存储过程中，务必在 END try 后补 CLOSE cur_name; DEALLOCATE cur_name;，别指望自动释放
• Oracle 的 REF CURSOR 传参时，接收端必须自己 OPEN/FETCH/CLOSE，漏关就内存泄漏

兼容性坑：MySQL 8.0 前不支持游标在存储过程外使用；sqlite 根本不支持游标语法，所有“游标逻辑”都得靠应用层模拟。

set-based 强制转换的关键检查点

把游标改写成 set-based，不是把循环体搬进 UPDATE 或 INSERT ... SELECT 就完事。核心是识别“每行依赖什么”：如果依赖上一行计算值、外部系统返回码、或运行时动态拼接的 SQL，那它大概率还不是真正的 set-based 问题，只是换了个容器装过程逻辑。

容易被忽略的点：

• UPDATE t1 SET col = (SELECT MAX(col) FROM t2 WHERE t2.id = t1.id) 看似 set-based，但如果子查询走不到索引，实际变成 N 次独立查询，比游标还慢
• 用 JOIN 替代游标更新时，确认 ON 条件不会产生笛卡尔积——尤其多对一关联时漏加 DISTINCT 或聚合，结果行数爆炸
• 批量操作加 TOP（SQL Server）或 LIMIT（PostgreSQL）分批提交，不是为了“像游标”，而是防事务日志撑爆、锁升级成表锁

真正卡住的，往往不是语法转换，而是业务规则里混进了不可下推的判断——比如“若调用支付接口返回 success 才更新状态”，这种只能切到应用层，硬塞进 SQL 只会让问题更模糊。