SQL游标是什么：工作原理与适用场景详解

为什么有时候必须“逐行”处理数据

在 SQL 开发中，我们常被教导要使用集合思维，避免逐行处理。大多数情况下，UPDATE、DELETE 或聚合函数能高效完成工作。但当业务逻辑依赖前一行的状态，或者需要调用外部系统（如发送 API 请求、写入日志文件）时，集合操作便显得力不从心。

此时，游标（Cursor）成为一种必要的工具。它允许应用程序逐行访问查询结果集，而不是一次性加载所有数据。简而言之，游标是数据库结果集的一个指针，让你能够控制遍历的节奏和每一行的处理逻辑。

游标如何逐行工作

游标的核心在于其生命周期管理。无论在哪种数据库系统中，游标的使用通常遵循四个标准步骤：声明（DECLARE）、打开（OPEN）、提取（FETCH）和关闭（CLOSE）。

1. 声明游标

首先，你需要定义游标关联的查询语句。这一步并不执行查询，只是告诉数据库准备一个什么样的结果集。

DECLARE my_cursor CURSOR FOR 
SELECT id, name, balance FROM accounts WHERE status = 'active';

2. 打开游标

执行 OPEN 命令后，数据库才会真正运行查询，并将结果集存储在临时区域或服务器内存中，指针指向第一行之前。

OPEN my_cursor;

3. 提取数据

使用 FETCH 命令逐行获取数据。每次执行，指针向下移动一行，并将当前行的列值赋值给变量。

FETCH NEXT FROM my_cursor INTO @id, @name, @balance;

4. 关闭游标

处理完成后，必须显式关闭游标以释放服务器资源。

CLOSE my_cursor;
DEALLOCATE my_cursor; -- 某些数据库需要额外释放

游标从打开、逐行提取到关闭的生命周期

上图展示了游标从声明到关闭的完整流程。注意，FETCH 是一个迭代过程，通常包裹在循环结构中。这种机制使得开发者可以在每一行数据上执行复杂的逻辑判断或外部交互，这是标准 SQL 语句难以直接实现的。

什么时候需要游标

虽然游标功能强大，但并非所有场景都适用。理解其适用边界比掌握语法更重要。

适用场景：逐行规则与外部副作用

当处理逻辑具有状态依赖性或外部副作用时，游标是合理的选择。例如：

• **复杂计算依赖前值：**计算每个用户的累计余额，且每一步的计算规则可能根据上一笔交易类型动态变化。
• **调用外部服务：**遍历用户列表，为每个满足条件的用户发送一封个性化邮件或调用第三方支付接口。这些操作无法在数据库内部通过纯 SQL 完成。
• **分批处理大事务：**为了避免长时间锁定表，有时会将大更新拆分为小批次，游标可以配合 FETCH NEXT 100 ROWS 实现可控的分批提交。

不适用场景：大批量集合变更

如果任务仅仅是“将所有活跃用户的余额增加 10%”，请使用：

UPDATE accounts SET balance = balance * 1.1 WHERE status = 'active';

这种集合操作由数据库引擎优化，速度远快于游标逐行更新。使用游标处理此类任务不仅代码冗长，还会导致严重的性能下降。

资源与集合操作取舍

选择游标意味着在灵活性与资源效率之间做出权衡。

资源占用风险

游标在执行期间会持有数据库连接和事务锁。如果忘记关闭游标，或者在游标遍历过程中执行了耗时的外部调用，会导致：

• **连接池耗尽：**其他请求无法获取数据库连接。
• **事务日志膨胀：**长事务阻止日志截断，影响数据库整体性能。
• **锁竞争：**长期持有的行锁或表锁可能阻塞其他用户的读写操作。

对比批量查询

下表总结了游标与集合操作的关键区别：

最佳实践建议

在使用游标时，请遵循以下原则以降低风险：

1. **最小化结果集：**在声明游标时，尽量通过 WHERE 子句过滤不必要的数据，减少遍历行数。
2. **快速遍历：**避免在 FETCH 循环中执行耗时操作。如果必须调用外部服务，考虑先将数据提取到应用层内存中处理，而非在数据库存储过程中长时间持有游标。
3. **确保关闭：**使用 TRY...FINALLY 或类似的异常处理结构，确保即使发生错误，游标也能被正确关闭和释放。
4. **考虑替代方案：**在某些数据库中，窗口函数（Window Functions）或 CTE 可以替代部分游标逻辑，实现更高效的逐行相关计算。

游标是 SQL 工具箱中的一把手术刀，精准但需谨慎使用。当集合操作无法满足业务逻辑的细微需求时，它提供了必要的控制力；但在大多数数据搬运和转换场景中，坚持集合思维依然是获得高性能的关键。

参考资料

• PostgreSQL cursors