存储过程是数据库中常用的程序化处理逻辑，很多开发者习惯使用游标对查询结果集进行逐行遍历处理，当数据量较大时，频繁的游标操作会带来严重的性能问题。游标的逐行处理模式会反复进行上下文切换，产生额外的内存和CPU开销，而集合操作可以一次性处理所有符合条件的数据，效率远高于行级循环。
游标操作的性能痛点
游标的核心特性是逐行遍历结果集，每处理一行都要经历取数、判断、执行逻辑的流程，当处理上万甚至更多数据时，这种模式的性能劣势会非常明显。常见的游标使用场景包括逐行更新数据、逐行计算汇总值、逐行关联其他表数据等，这些场景大多可以通过集合操作替代。
典型游标处理示例
以下是一个常见的游标逐行更新订单状态的存储过程示例，逻辑是遍历所有未完成的订单，根据订单金额更新对应的等级：
-- 创建测试表
CREATE TABLE order_info (
order_id INT PRIMARY KEY,
order_amount DECIMAL(10,2),
order_level VARCHAR(20),
is_finished INT
);
-- 插入测试数据
INSERT INTO order_info VALUES(1, 100.50, NULL, 0);
INSERT INTO order_info VALUES(2, 300.00, NULL, 0);
INSERT INTO order_info VALUES(3, 500.00, NULL, 0);
INSERT INTO order_info VALUES(4, 800.00, NULL, 0);
-- 游标方式逐行更新订单等级
DELIMITER //
CREATE PROCEDURE update_order_level_cursor()
BEGIN
DECLARE v_order_id INT;
DECLARE v_order_amount DECIMAL(10,2);
DECLARE done INT DEFAULT 0;
-- 定义游标
DECLARE order_cursor CURSOR FOR SELECT order_id, order_amount FROM order_info WHERE is_finished = 0;
-- 定义结束标记
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
OPEN order_cursor;
read_loop: LOOP
FETCH order_cursor INTO v_order_id, v_order_amount;
IF done THEN
LEAVE read_loop;
END IF;
-- 逐行判断更新等级
IF v_order_amount < 200 THEN
UPDATE order_info SET order_level = '普通' WHERE order_id = v_order_id;
ELSEIF v_order_amount < 500 THEN
UPDATE order_info SET order_level = '高级' WHERE order_id = v_order_id;
ELSE
UPDATE order_info SET order_level = '特级' WHERE order_id = v_order_id;
END IF;
END LOOP;
CLOSE order_cursor;
END //
DELIMITER ;
用集合操作JOIN替代游标
上述游标的逻辑本质是逐行判断订单金额并更新对应字段，我们可以将订单等级的判断逻辑转化为条件表达式，用一条UPDATE语句结合CASE表达式一次性完成所有数据的更新，完全不需要游标。
集合操作优化后的存储过程
优化后的存储过程去掉了游标定义、打开、关闭等步骤，仅用一条更新语句完成所有处理：
DELIMITER //
CREATE PROCEDURE update_order_level_set()
BEGIN
-- 用CASE表达式一次性更新所有符合条件的订单等级
UPDATE order_info
SET order_level = CASE
WHEN order_amount < 200 THEN '普通'
WHEN order_amount < 500 THEN '高级'
ELSE '特级'
END
WHERE is_finished = 0;
END //
DELIMITER ;
对比两种方式，优化后的存储过程减少了大量逐行遍历的开销，当订单表数据量达到十万级以上时，执行效率可以提升数十倍甚至更多。
复杂场景的JOIN替代方案
如果游标的逻辑涉及多表关联处理，比如逐行关联用户表获取用户信息再更新订单表，同样可以用JOIN替代游标。以下是一个游标逐行关联用户表更新订单用户名的示例：
-- 创建用户表
CREATE TABLE user_info (
user_id INT PRIMARY KEY,
user_name VARCHAR(50)
);
-- 插入用户测试数据
INSERT INTO user_info VALUES(1, '张三');
INSERT INTO user_info VALUES(2, '李四');
INSERT INTO user_info VALUES(3, '王五');
-- 订单表增加用户ID字段
ALTER TABLE order_info ADD COLUMN user_id INT;
-- 更新订单的用户ID测试数据
UPDATE order_info SET user_id = 1 WHERE order_id = 1;
UPDATE order_info SET user_id = 2 WHERE order_id = 2;
UPDATE order_info SET user_id = 3 WHERE order_id = 3;
UPDATE order_info SET user_id = 1 WHERE order_id = 4;
-- 游标方式逐行关联用户表更新订单用户名
DELIMITER //
CREATE PROCEDURE update_order_username_cursor()
BEGIN
DECLARE v_order_id INT;
DECLARE v_user_id INT;
DECLARE v_user_name VARCHAR(50);
DECLARE done INT DEFAULT 0;
DECLARE order_cursor CURSOR FOR SELECT order_id, user_id FROM order_info WHERE is_finished = 0;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
OPEN order_cursor;
read_loop: LOOP
FETCH order_cursor INTO v_order_id, v_user_id;
IF done THEN
LEAVE read_loop;
END IF;
-- 逐行查询用户名
SELECT user_name INTO v_user_name FROM user_info WHERE user_id = v_user_id;
-- 更新订单用户名
UPDATE order_info SET order_level = v_user_name WHERE order_id = v_order_id;
END LOOP;
CLOSE order_cursor;
END //
DELIMITER ;
上述逻辑可以用JOIN直接关联两张表，一次性完成更新：
DELIMITER //
CREATE PROCEDURE update_order_username_join()
BEGIN
-- 用JOIN关联用户表和订单表，一次性更新所有订单的用户名
UPDATE order_info o
JOIN user_info u ON o.user_id = u.user_id
SET o.order_level = u.user_name
WHERE o.is_finished = 0;
END //
DELIMITER ;
游标的适用场景
虽然集合操作和JOIN可以替代大部分游标的行级循环场景，但游标仍有其适用场景：当处理逻辑必须逐行执行，且前后行的处理存在依赖关系，无法通过集合运算一次性完成时，游标仍然是合理的选择。比如需要逐行生成连续的流水号、逐行处理有前后顺序依赖的日志数据等场景，此时使用游标更符合逻辑需求。
优化建议总结
- 优先使用集合操作替代游标的行级循环，减少逐行遍历的开销
- 涉及多表关联的处理逻辑，尽量用JOIN一次性完成数据关联和更新
- 只有在处理逻辑存在强行级依赖，无法用集合运算实现时，才选择使用游标
- 如果必须使用游标，尽量缩小游标查询的结果集范围，只遍历必要的数据