游标比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 保证释放
