在数据库开发的日常工作中，你是否遇到过这样的情况：你需要对查询返回的每一行数据进行复杂的逻辑判断，或者进行逐行的更新操作，而标准的 SQL 语句似乎无法满足这种精细化的需求？这时候，游标（Cursor） 就成了我们手中最锋利的武器。
在这篇文章中，我们将深入探讨数据库管理系统（DBMS）中的游标技术。我们将不仅停留在表面的定义，还会一起剖析游标的工作原理、隐式与显式游标的区别、关键的属性应用，以及最重要的——如何在真实的开发场景中高效地使用它们。无论你是在使用 Oracle、SQL Server 还是 MySQL，理解游标都将是你从“写出能运行的 SQL”进阶到“写出高性能 SQL”的关键一步。
什么是游标？
简单来说，每当我们在数据库中执行一条 SQL 语句（DML）时，数据库会在系统内存中分配一个临时的工作区域来处理这条语句。这个临时的内存区域，以及指向其中数据的指针，就是我们所说的游标。
你可以把它想象成内存中的一张“虚拟表”或者一个“指针”。虽然一个查询可能返回成千上万行数据，但关系型数据库的本质是面向集合的，而我们的应用逻辑往往是面向过程的（一次处理一件事）。游标就是连接这两个世界的桥梁。它允许我们逐行地处理数据，而不是一次性处理整个结果集。
游标的两种主要类型
在 PL/SQL（以及许多其他数据库的扩展语言中），游标主要分为两大类。理解它们的区别对于编写正确的代码至关重要。
- 隐式游标：这是数据库自动为我们创建的。每当你执行一条 INSERT、UPDATE、DELETE 语句，或者执行一条返回单行的 SELECT 语句时，数据库都会自动创建一个隐式游标来处理操作。你不需要显式地声明或打开它，它是“幕后英雄”。
- 显式游标：这是由我们开发者显式定义和控制的游标。通常用于处理返回多行数据的 SELECT 查询。因为我们需要逐行遍历数据并决定每行该做什么，所以我们需要掌握控制权：声明、打开、提取数据、最后关闭它。
显式游标详解与实战
显式游标给了我们对数据处理的完全控制权。让我们来看看创建和使用显式游标的标准生命周期。这个过程就像是我们在餐厅点餐的过程：
- 声明游标：告诉服务员（数据库）你想要什么菜。
- 打开游标：后厨开始备菜，数据被加载到内存中。
- 提取游标：服务员把菜一道一道端上来给你吃。
- 关闭游标：用餐结束，清空桌子，释放内存。
#### 1. 游标声明
这是在 PL/SQL 块的声明部分完成的。我们需要给游标起个名字，并告诉它要查什么数据。
-- 语法结构
CURSOR IS
SELECT FROM WHERE ;
#### 2. 打开游标
执行查询，将数据锁定并加载到内存中。
-- 语法结构
OPEN ;
#### 3. 提取游标
这是最关键的一步。游标一次只能指向一行数据。FETCH 语句会将当前行的数据提取到我们定义的变量中，并将指针移动到下一行。
-- 语法结构
FETCH INTO ;
#### 4. 关闭游标
处理完数据后，必须关闭游标以释放数据库资源。如果不关闭，可能会导致内存泄漏或锁定问题。
-- 语法结构
CLOSE ;
#### 实战示例：批量处理员工薪资
假设我们有一个需求：遍历所有员工，给特定城市的员工打印一条信息。我们来看看完整的代码是如何运作的。
DECLARE
-- 定义变量来存储每一行的数据
-- 使用 %TYPE 可以确保变量类型与表列类型一致，这是最佳实践
empId employees.EMPLOYEEID%TYPE;
empName employees.EMPLOYEENAME%TYPE;
empCity employees.EMPLOYEECITY%TYPE;
-- 声明游标：选择我们需要处理的数据集
CURSOR c_employees IS
SELECT EMPLOYEEID, EMPLOYEENAME, EMPLOYEECITY
FROM employees;
BEGIN
-- 第一步：打开游标，执行查询
OPEN c_employees;
-- 第二步：开始循环，逐行提取
LOOP
-- 提取当前行数据到变量
FETCH c_employees INTO empId, empName, empCity;
-- 退出条件：当没有数据找到时退出循环
-- %NOTFOUND 是游标的属性，我们稍后会详细讲解
EXIT WHEN c_employees%NOTFOUND;
-- 业务逻辑：在这里我们可以做任何事，比如更新、插入或仅仅是打印
DBMS_OUTPUT.PUT_LINE(‘员工ID: ‘ || empId || ‘, 姓名: ‘ || empName || ‘, 城市: ‘ || empCity);
END LOOP;
-- 第三步：关闭游标，释放资源
CLOSE c_employees;
END;
/
代码解析：
在这个例子中，我们首先声明了与表结构匹配的变量。然后定义了游标 INLINECODEfc15bbc6 来获取数据。在 INLINECODEebff8de1 之后，我们打开游标，进入循环。在循环体内，INLINECODE6968afe4 语句就像取号机一样，每次拿出一行数据。最关键的 INLINECODE3416fe49 语句防止了死循环——当数据取完后，INLINECODEd73ffed4 变为 TRUE，循环结束。最后，别忘了 INLINECODE4addad42，这是一个优秀程序员的好习惯。
隐式游标及其强大属性
虽然显式游标在处理多行数据时很有用，但在处理单行操作（如 INSERT、UPDATE、DELETE）时，我们通常依赖隐式游标。为了方便我们获取这些操作的状态，PL/SQL 提供了一个特殊的游标标识符——INLINECODE64d0afdc。我们不需要声明它，直接使用 INLINECODEda71ee5d 即可。
隐式游标最强大的地方在于它的四个属性，它们能告诉我们刚才的操作“发生了什么”：
-
%FOUND：刚才的操作影响到了行吗？如果是，返回 TRUE。
-
%NOTFOUND：刚才的操作没影响到任何行吗？如果是，返回 TRUE。
-
%ROWCOUNT：刚才的操作一共影响了多少行？返回具体的数字。
-
%ISOPEN：游标是打开状态吗？（对于隐式游标，这个属性永远是 FALSE，因为数据库会自动打开和关闭它）。
> 注意： 这些属性必须在事务执行后、下一次事务执行前立即查看，否则值会被重置或覆盖。
#### 准备工作：创建测试环境
为了演示这些属性，我们需要一个干净的表。让我们先创建一个 employees 表并插入一些测试数据。
-- 创建表结构
CREATE TABLE employees (
EMPLOYEEID NUMBER(10) NOT NULL,
EMPLOYEENAME VARCHAR2(50) NOT NULL,
EMPLOYEECITY VARCHAR2(50)
);
-- 插入测试数据
INSERT INTO employees (employeeId, employeeName, employeeCity) VALUES (1, ‘张三‘, ‘北京‘);
INSERT INTO employees (employeeId, employeeName, employeeCity) VALUES (2, ‘李四‘, ‘上海‘);
INSERT INTO employees (employeeId, employeeName, employeeCity) VALUES (3, ‘王五‘, ‘广州‘);
-- 确认数据已存在
SELECT * FROM employees;
#### 实战场景 1：使用 %FOUND 进行条件更新
假设我们要删除 ID 为 2 的员工，如果删除成功（即确实存在这个人），我们就插入一条新记录作为替补。这是一个非常典型的“存在则删除，成功则补偿”的逻辑。
-- 创建一个临时表用于测试，以免破坏主表
CREATE TABLE tempory_employee AS SELECT * FROM employees;
DECLARE
employeeNo NUMBER(4) := 2;
BEGIN
-- 尝试删除指定 ID 的员工
DELETE FROM tempory_employee WHERE employeeId = employeeNo;
-- 检查刚才的 DELETE 是否成功
IF SQL%FOUND THEN
-- 如果删除成功 (SQL%FOUND 为 TRUE)，则插入替补员工
INSERT INTO tempory_employee (employeeId, employeeName, employeeCity)
VALUES (2, ‘赵六‘, ‘深圳‘);
DBMS_OUTPUT.PUT_LINE(‘操作成功：已删除原记录并插入替补员工。‘);
ELSE
DBMS_OUTPUT.PUT_LINE(‘操作失败：未找到指定 ID 的员工。‘);
END IF;
END;
/
-- 查看结果
SELECT * FROM tempory_employee;
结果分析：
运行上述代码后，你会发现 ID 为 2 的“李四”不见了，取而代之的是“赵六”。这是因为 INLINECODEc09df684 语句找到了匹配的行，所以 INLINECODE5089553f 返回了 INLINECODEaa1ada70，触发了 INLINECODE3c1b86f9 块中的 INSERT 语句。
#### 实战场景 2：结合 %FOUND 进行跨表更新
现在让我们看一个更复杂的例子。我们仍然先尝试删除某条记录，如果删除成功（说明该 ID 确实存在过），我们就更新主表 employees 中 ID 为 1 的员工的城市信息。这在处理关联数据校验时非常有用。
-- 再创建一个临时表进行测试
CREATE TABLE tempory_employee1 AS SELECT * FROM employees;
DECLARE
employeeNo NUMBER(4) := 2;
BEGIN
-- 先删除临时表中的记录
DELETE FROM tempory_employee1 WHERE employeeId = employeeNo;
-- 只有当删除成功时，才去更新主表
IF SQL%FOUND THEN
-- 更新主表 employees 中 ID 为 1 的城市
UPDATE employees
SET employeeCity = ‘成都‘
WHERE employeeId = 1;
DBMS_OUTPUT.PUT_LINE(‘验证通过：已更新主表数据。‘);
ELSE
DBMS_OUTPUT.PUT_LINE(‘验证失败：无操作。‘);
END IF;
END;
/
-- 查看主表 employees 的变化
-- ID 为 1 的 ‘张三‘ 的城市应该变成了 ‘成都‘
SELECT * FROM employees;
#### 实战场景 3：使用 %ROWCOUNT 统计批量操作
有时候我们不仅仅关心操作是否成功，还关心影响了多少行。%ROWCOUNT 就是为此准备的。
DECLARE
BEGIN
-- 更新所有来自北京的城市为 ‘首都‘
UPDATE employees SET employeeCity = ‘首都‘ WHERE employeeCity = ‘北京‘;
-- 输出受影响的行数
DBMS_OUTPUT.PUT_LINE(‘本次更新一共影响了 ‘ || SQL%ROWCOUNT || ‘ 名员工。‘);
IF SQL%ROWCOUNT = 0 THEN
DBMS_OUTPUT.PUT_LINE(‘警告：没有匹配的记录被更新！‘);
END IF;
END;
/
在这个例子中，如果之前“张三”在北京，这条语句会将他更新为“首都”，并打印出“本次更新一共影响了 1 名员工”。这对于批量操作后的日志记录非常关键。
最佳实践与性能优化建议
既然我们已经掌握了游标的用法，我想以一个资深开发者的身份，跟你分享一些在实际项目中的避坑指南。
- 避免在游标循环中执行 DML 操作（如果可能）：
这是最常见的性能杀手。如果你写了一个游标遍历 10,000 行数据，并且在每一行里都执行一次 INLINECODE401d1408，这被称为“逐行处理”，性能极差。更好的做法是尝试使用单一的 SQL 语句（如 INLINECODEc09fa25d）来批量处理，或者使用 INLINECODE8ff32441 和 INLINECODEc31eb7be 进行批量绑定（这是 PL/SQL 高级优化的重点）。
- 显式游标一定要关闭：
虽然现代数据库通常会在会话结束时自动清理资源，但在长时间运行的存储过程或高频调用的代码中，未关闭的游标会占用大量内存（PGA），甚至导致“游标泄漏”错误。养成 INLINECODE5a08ab04 之后必有 INLINECODE2817bf9d 的习惯，最好使用异常处理块（EXCEPTION）来确保即使出错也能关闭游标。
- 善用 FOR 循环遍历游标：
如果你只是需要简单的遍历，PL/SQL 提供了一种更简洁的写法：FOR rec IN cursor_name LOOP ... END LOOP;。这种写法会自动声明变量、自动打开、自动提取、自动关闭游标。它不仅代码更少，而且更安全，因为你永远不会忘记关闭游标。
-- 更简洁的写法示例
BEGIN
FOR emp_rec IN (SELECT EMPLOYEEID, EMPLOYEENAME FROM employees)
LOOP
DBMS_OUTPUT.PUT_LINE(emp_rec.EMPLOYEENAME);
END LOOP;
END;
- 注意隐式游标的生命周期：
记住，INLINECODE1a34c596 属性只保存最近一条 SQL 语句的执行结果。如果你在 INLINECODE4080eafe 后面加了一行无关的 INLINECODE535029b2，再去查 INLINECODEab83e03d，得到的就不是 UPDATE 的行数了。
总结与思考
通过这篇文章，我们不仅掌握了游标在 DBMS 中的定义和分类，更重要的是，我们学会了如何利用显式游标来驾驭多行数据，以及如何利用隐式游标的属性（INLINECODE96bc10fb, INLINECODE433d3a5b）来编写健壮的业务逻辑。
游标就像是数据库赋予我们的手术刀，虽然有时候用大刀（集合操作）砍肉更快，但在处理精细的、逐行的逻辑判断时，游标是不可或缺的。你在接下来的项目中，不妨尝试识别一下那些在应用层代码里循环查数据库的场景，思考一下是否可以将其重构为数据库内部的游标处理，这往往能带来巨大的性能提升。
希望这篇深入浅出的指南能帮助你更好地理解和使用游标。祝你在数据管理的道路上越走越远！