SQL 游标 vs set-based 操作的内存消耗与效率对比

游标比select慢且吃内存，因其逐行拉取结果集至缓冲区并频繁网络往返或内存拷贝；而select可流式返回、支持批量优化与谓词下推。

游标遍历为什么比 SELECT 慢还吃内存

因为游标（DECLARE CURSOR）本质是把结果集一行行拉进客户端或服务端缓冲区，每 FETCH 一次就触发一次网络往返或内存拷贝；而 SELECT 是一次性生成执行计划、流式返回结果，数据库能做批量优化、索引跳过、谓词下推。

常见错误现象：Cursorfetch: The cursor was not declared. 或执行时 tempdb 突然暴涨，甚至 Out of memory —— 尤其在 sql Server 中，静态/键集游标会把整个结果集缓存到 tempdb。

• 使用场景：仅当必须「逐行处理 + 条件分支 + 多次调用存储过程」时才考虑游标，比如给每个用户发定制邮件并记录发送状态
• 参数差异：DECLARE CURSOR LOCAL FAST_forWARD READ_ONLY 比默认游标轻量得多，但仍是逐行语义，无法规避根本开销
• 性能影响：10 万行数据，游标平均耗时可能是等效 UPDATE 的 5–20 倍，CPU 和内存占用呈线性增长

UPDATE / delete 能 set-based 就别写游标

绝大多数业务逻辑——比如“把所有订单状态为 'pending' 且超时的改成 'expired'”——完全可以用一条 UPDATE 完成，不需要游标。

容易踩的坑：有人用游标是为了在循环里加日志、调用 EXEC 或做复杂判断，结果发现 UPDATE ... FROM 或 WITH CTE 加 CASE WHEN 就能覆盖 90% 场景。

• 示例对比：

  UPDATE orders SET status = 'expired' WHERE status = 'pending' AND created_at < DATEADD(hour, -24, GETDATE());

  vs 游标逐行查+判断+更新

• 兼容性影响：mysql 8.0+、postgresql、SQL Server 都支持窗口函数和 CTE，用 ROW_NUMBER() 分页更新也比游标安全
• 注意：如果更新逻辑依赖上一行结果（比如累计余额），那确实是游标或递归 CTE 的合理场景，但得先确认是否真不可 set-based 化

游标在不同数据库里的内存行为差异

不是所有游标都一样重。SQL Server 默认游标最“贪”，PostgreSQL 的 DECLARE ... SCROLL 游标只存查询计划，真正 FETCH 才取数据；sqlite 根本不支持服务器端游标，所谓游标只是 API 层封装。

常见错误现象：ORA-01000: maximum open cursors exceeded（oracle）——没及时 CLOSE 或 DEALLOCATE，连接泄漏；或者在循环里反复 DECLARE 却不释放。

• SQL Server：优先用 LOCAL FAST_FORWARD，避免 KEYSET 或 Static，它们强制物化结果集
• PostgreSQL：用 DECLARE c CURSOR FOR SELECT ... 后，FETCH 100 只拉 100 行，内存压力可控
• MySQL：5.7 及以前不支持服务端游标，所谓游标是客户端模拟，实际还是全拉再遍历，慎用

怎么快速判断该不该用游标

问自己三个问题：是否必须按特定顺序逐行处理？是否每一行操作都依赖前一行的运行时结果？是否涉及跨连接、跨数据库或外部系统调用？只要有一个“否”，大概率可以改写。

最容易被忽略的地方：很多人把“逻辑复杂”等同于“必须游标”，其实复杂逻辑往往藏在 WHERE、CASE、子查询或 CTE 里，而不是控制流里。

实操建议：
• 先写出等效的 set-based 语句，哪怕多嵌套几层 WITH
• 用 EXPLAIN（PostgreSQL/MySQL）或执行计划（SQL Server）看是否走索引、是否临时表膨胀
• 如果真要游标，务必配对 OPEN/FETCH/CLOSE/DEALLOCATE，尤其在存储过程中加 BEGIN try ... END TRY BEGIN catch ... END CATCH 保证释放