MySQL存储函数不支持游标，因其设计要求确定性与无副作用；需逐行处理时应改用存储过程，后者支持DECLARE CURSOR、OPEN、FETCH及LOOP等完整控制流语法。

MySQL存储函数里不能用游标

MySQL的FUNCTION（函数）不支持游标、DECLARE CURSOR、OPEN、FETCH等语句。这是硬性限制——函数设计初衷是返回单个值，必须是确定性、无副作用的。一旦允许游标，就可能产生读写状态、影响并发或破坏复制一致性。

如果你看到“在函数中用游标”的需求，实际应转向：PROCEDURE（存储过程）。只有存储过程才支持完整控制流和游标操作。

在存储过程中声明和打开游标的基本写法

游标必须在DECLARE语句块中定义，且必须在所有DECLARE变量、条件、处理器之后、BEGIN主体之前声明。顺序错会报错：ERROR 1337 (42000): Variable or condition declaration after cursor or handler declaration。

典型结构如下：

DROP PROCEDURE IF EXISTS process_orders;
DELIMITER $$
CREATE PROCEDURE process_orders()
BEGIN
  DECLARE done INT DEFAULT FALSE;
  DECLARE v_order_id INT;
  DECLARE v_amount DECIMAL(10,2);
<p>-- 游标必须在变量声明之后、handler之前
DECLARE cur_orders CURSOR FOR 
SELECT order_id, amount FROM orders WHERE status = 'pending';</p><p>-- 必须声明CONTINUE HANDLER捕获NOT FOUND，否则FETCH失败直接退出
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;</p><p>OPEN cur_orders;
read_loop: LOOP
FETCH cur_orders INTO v_order_id, v_amount;
IF done THEN
LEAVE read_loop;
END IF;
-- 处理每一行：比如更新、插入、调用其他逻辑
UPDATE orders SET status = 'processed' WHERE order_id = v_order_id;
END LOOP;
CLOSE cur_orders;
END$$
DELIMITER ;

遍历大型结果集时的关键性能与安全陷阱

游标本质是逐行取数据，对百万级表默认会把整个结果集加载进内存（尤其InnoDB），极易OOM或锁表太久。不是“能跑通”就代表能上线。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 务必加WHERE条件缩小扫描范围，避免SELECT * FROM huge_table
• 游标查询必须走索引，检查EXPLAIN输出的key字段是否非NULL
• 不要在循环内执行高开销操作（如远程API调用、复杂子查询），拆到应用层更可控
• 如果只是做统计或批量更新，优先用单条SQL替代游标，例如：UPDATE orders SET status='done' WHERE ...
• 事务中使用游标时，注意autocommit=0下长事务会持锁，考虑分批次（加LIMIT + OFFSET模拟分页，但需配合主键规避幻读）

为什么CONTINUE HANDLER FOR NOT FOUND不能省略

游标到达末尾时，FETCH不会报错，但会把目标变量设为NULL（即使原字段不允许NULL）。如果没有NOT FOUND处理器，done标志永远不会被触发，导致无限循环或漏处理最后一行。

常见错误写法：

-- ❌ 错误：没设handler，FETCH后v_order_id变成NULL，但done仍是FALSE
FETCH cur_orders INTO v_order_id, v_amount;
IF v_order_id IS NULL THEN LEAVE read_loop; END IF;

正确方式始终依赖NOT FOUND信号，而不是字段值判断。MySQL官方文档明确说明：NOT FOUND是唯一可靠的游标结束标识。

真正麻烦的是嵌套游标或动态SQL场景——handler作用域容易出错，这种时候不如直接放弃游标，改用应用层分页+批处理。