游标吃内存是因为其本质是将结果集提前物化到内存或tempdb中，即使只取1行，STATIC/KEYSET游标也会缓存全部数据；SQL Server声明即生成执行计划并缓存，PostgreSQL FETCH后持续占用上下文，Oracle隐式游标逐行解析导致堆内存线性增长。
游标为什么吃内存：从执行计划看数据驻留
SQL 游标（DECLARE CURSOR）本质是把结果集“拖进内存里一行行翻”，哪怕只取 1 行，SQL Server 或 PostgreSQL 也常提前物化整个结果集（尤其 STATIC 或 KEYSET 类型）。你看到的 FETCH NEXT 并不意味着只加载当前行——底层可能已把百万行全读进 tempdb 或工作内存。
- SQL Server 中，
DECLARE CURSOR FOR SELECT ...后立即触发优化器生成完整执行计划，且多数游标类型会缓存全部键值或数据副本 - PostgreSQL 的
DECLARE my_cursor CURSOR FOR ...虽延迟执行，但一旦FETCH开始，查询就会持续占用连接上下文和内存，无法被 GC 或释放 - Oracle 的隐式游标（如 PL/SQL 中
FOR rec IN (SELECT ...)）看似简洁，实际仍是逐行打开、解析、绑定，每轮循环都触发一次 row source 拉取，堆内存压力随字段数和行数线性增长
set-based 替代游标的三个硬约束条件
不是所有游标逻辑都能直接改写成 set-based。真正能安全替换的，必须同时满足：
- 目标操作不依赖前一行的计算结果（比如“累计求和”需改用
SUM() OVER (ORDER BY ...)，而非靠游标变量累加） - 没有跨行状态传递（如“若上一行 status = 'fail'，则本行跳过更新”——这类必须用
LAG()或 CTE + 排序模拟，不能简单 DELETE/UPDATE） - 事务边界清晰：游标常在循环内做
UPDATE+COMMIT分批提交，set-based 则需确认单条UPDATE是否可接受长事务，或改用TOP (n) WITH (UPDLOCK, READPAST)分页更新
强制优化器走 set-based 的实操技巧
有时你写了 set-based 语句，但执行计划仍出现 Nested Loops 或 Table Spool——说明优化器“误判”了数据分布。这时要主动干预：
- 对 JOIN 字段补全统计信息：
UPDATE STATISTICS dbo.orders WITH FULLSCAN，尤其当表刚批量导入后 - 避免在 WHERE 中对字段做函数操作：
WHERE YEAR(order_date) = 2024会禁用索引；改用WHERE order_date >= '2024-01-01' AND order_date - SQL Server 可临时加提示：
SELECT ... FROM orders o INNER LOOP JOIN customers c ON ...（慎用，仅用于验证逻辑是否真能 set-based 执行） - PostgreSQL 中，
SET enable_hashjoin = off有时能逼出 Merge Join，暴露排序缺失问题，进而补ORDER BY或索引
游标残留导致的隐形内存泄漏
很多人以为 CLOSE CURSOR 就万事大吉，其实不然。未显式 DEALLOCATE 的游标会持续持有执行上下文资源，尤其在存储过程中反复声明同名游标时：
- SQL Server 中，
DECLARE @cur CURSOR是局部变量，但游标资源本身在 session 级分配；不DEALLOCATE，下次同名DECLARE会报错The cursor name is already in use - PostgreSQL 不报错，但
DECLARE多次会产生多个游标句柄，每个都占 backend 内存，直到连接断开 - 最危险的是异常路径：存储过程里游标在 TRY 块中声明，但 CATCH 里忘了
CLOSE+DEALLOCATE，一次失败就留下僵尸游标
真正稳妥的做法是：所有游标操作必须包裹在 BEGIN TRY ... END TRY BEGIN CATCH ... CLOSE; DEALLOCATE; ... END CATCH 中，且不要依赖自动释放。
