游标被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跳过中间行比循环FETCH10 次高效得多 - 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 只会让问题更模糊。
