MySQL FETCH游标时为何出现数据重复？

Question

在使用 MySQL 存储过程中通过 FETCH 游标逐行读取结果集时，部分开发者常遇到数据重复的问题。典型表现为：循环中多次 FETCH 到相同记录，导致业务逻辑异常。该问题通常源于未正确判断游标结束标志（如 `NOT FOUND` 条件）或在 `FETCH` 语句后未及时更新控制变量，致使循环未能正常退出。此外，若在 `DECLARE CONTINUE HANDLER FOR NOT FOUND` 中处理不当，也可能造成最后一次有效数据被重复处理。需确保游标遍历逻辑严谨，避免因流程控制失误引发数据重复读取。

Answer 1

一、MySQL 存储过程中游标 FETCH 数据重复问题的常见现象

在使用 MySQL 存储过程处理复杂业务逻辑时，开发者常借助游标（CURSOR）逐行遍历查询结果集。然而，一个典型且隐蔽的问题是：在循环中多次 FETCH 到相同记录，导致数据被重复处理。这种异常行为通常不会立即报错，但会引发数据一致性问题，例如重复插入、计数错误或状态更新混乱。

例如，在订单批处理场景中，若某条订单因游标控制不当被两次处理，可能导致库存扣减两次，造成严重业务事故。此类问题多出现在以下环节：

• 未正确设置游标结束标志（NOT FOUND）
• FETCH 语句后未及时更新控制变量
• CONTINUE HANDLER 处理逻辑干扰了主循环流程
• 循环结构设计不合理，如 WHILE 条件判断位置错误

二、问题根源深度剖析

MySQL 游标的机制依赖于三个核心组件：声明游标、定义 NOT FOUND 处理器、通过 FETCH 获取数据。当 FETCH 尝试读取超出结果集末尾的数据时，系统会触发一个“no data”条件，此时若已声明 CONTINUE HANDLER FOR NOT FOUND，则该处理器会被激活，并继续执行后续语句，而不会中断过程。

常见的错误模式如下表所示：

错误类型	描述	后果
提前设置 done = 1	在 FETCH 前设置结束标志	首条记录即被跳过
FETCH 后无判断直接处理	未检查是否已达末尾	最后一条数据重复处理
HANDLER 中修改业务变量	在 NOT FOUND 中执行非标志赋值操作	副作用导致逻辑错乱
WHILE 条件位置不当	在 FETCH 前判断 done	无法捕获最后一次有效数据

三、标准解决方案与最佳实践

为避免数据重复读取，必须遵循严格的游标使用范式。以下是推荐的标准结构：

DELIMITER $$
CREATE PROCEDURE ProcessOrders()
BEGIN
    DECLARE done INT DEFAULT FALSE;
    DECLARE order_id INT;
    DECLARE order_amount DECIMAL(10,2);

    -- 声明游标
    DECLARE cur_orders CURSOR FOR 
        SELECT id, amount FROM orders WHERE status = 'pending';

    -- 定义 CONTINUE HANDLER
    DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

    OPEN cur_orders;

    read_loop: LOOP
        FETCH cur_orders INTO order_id, order_amount;
        
        IF done THEN
            LEAVE read_loop;
        END IF;

        -- 处理每条记录
        UPDATE orders SET status = 'processed' WHERE id = order_id;
        INSERT INTO audit_log(order_id, action) VALUES (order_id, 'processed');
    END LOOP;

    CLOSE cur_orders;
END$$
DELIMITER ;

    

关键点在于：CONTINUE HANDLER 仅用于设置标志位 done = TRUE，所有业务处理必须在 IF done THEN LEAVE 判断之后进行，确保最后一次 FETCH 成功后才执行逻辑，而在触发 NOT FOUND 后不再进入处理分支。

四、流程图解析游标控制流

为了更清晰地展示正确的游标执行路径，以下使用 Mermaid 流程图描述整个控制流程：

graph TD
            A[开始] --> B[OPEN 游标]
            B --> C[LOOP 开始]
            C --> D[FETCH 下一行]
            D --> E{是否触发 NOT FOUND?}
            E -- 是 --> F[SET done = TRUE]
            F --> G{done 是否为 TRUE?}
            E -- 否 --> G
            G -- 是 --> H[LEAVE 循环]
            G -- 否 --> I[处理当前记录]
            I --> C
            H --> J[CLOSE 游标]
            J --> K[结束]

从图中可见，只有在 FETCH 成功获取数据且 done 仍为 FALSE 时，才会进入业务处理环节。一旦触发 NOT FOUND，done 被设为 TRUE，下一轮循环将退出，从而杜绝重复处理。

五、高级调试技巧与规避策略

对于已有存储过程出现数据重复的情况，可采用以下调试手段定位问题：

1. 在 FETCH 后添加日志输出，打印 order_id 和 done 状态
2. 临时将业务操作替换为 SELECT 输出，观察是否有多次输出同一 ID
3. 检查 HANDLER 是否包含除赋值外的其他语句
4. 验证 FETCH 是否位于条件判断之前
5. 使用 SQL tracing 工具（如 Performance Schema）跟踪执行路径
6. 在测试环境中模拟空结果集，确认 HANDLER 不会导致误处理
7. 对游标变量命名规范化，避免与表字段冲突
8. 考虑使用临时表 + WHILE 循环替代游标，提升性能与可控性
9. 在高并发场景下评估游标锁行为，防止阻塞
10. 定期审查存储过程代码，建立代码评审清单