MySQL自定义函数中禁止使用游标，因其设计要求纯计算、无副作用，而游标涉及状态变更与资源持有，仅允许在存储过程中使用。
不能在 MySQL 自定义函数中使用游标。 这是 MySQL 的硬性限制，不是写法或版本问题 —— CURSOR 只允许出现在存储过程（PROCEDURE）和存储函数（FUNCTION）的「存储例程」中，但函数（FUNCTION）本身被明确禁止声明游标。
为什么 MySQL 函数里 DECLARE CURSOR 会报错？
当你在 CREATE FUNCTION 里写 DECLARE cur CURSOR FOR ...，MySQL 会直接抛出错误：ERROR 1337 (42000): Variable or condition declaration after cursor or handler declaration 或更早的语法拒绝（如 ERROR 1064）。根本原因在于：MySQL 函数设计目标是「纯计算、无副作用、可内联优化」，而游标必然伴随状态变更（OPEN/FETCH）、资源持有（结果集缓存）、以及隐式事务行为（哪怕只读），这与函数的语义冲突。
常见误判点：
- 把存储过程（
PROCEDURE）和函数（FUNCTION）混用，以为“都能写逻辑”就该支持相同语法 - 看到 Oracle/SQL Server 允许函数用游标，误以为 MySQL 也一样
- 试图用
SELECT ... INTO替代游标，在函数里做单行赋值 —— 这只能处理一行，且不解决「逐行+分支逻辑」需求
想逐行处理数据，该用 PROCEDURE 还是绕开游标？
如果业务逻辑确实需要「对结果集每行执行不同分支判断+写多张表+调用其他逻辑」，必须用 PROCEDURE。这是唯一合法路径。别尝试 hack，比如：
- 在函数里调用存储过程 —— MySQL 不允许函数内调用含副作用的操作（包括
CALL） - 用临时表 +
WHILE+SELECT ... LIMIT 1 OFFSET n模拟游标 —— 性能极差、无法保证顺序、并发下易错 - 把逻辑全塞进一条 SQL（如
CASE WHEN+ 多表 JOIN）—— 可行但可读性崩坏，且无法写入中间日志表或触发条件分支
正确做法是：把原计划写在函数里的逻辑，完整迁移到 PROCEDURE 中，按标准四步走：DECLARE CURSOR → OPEN → 循环 FETCH → CLOSE，并配好 CONTINUE HANDLER FOR NOT FOUND。
CONTINUE HANDLER 和循环退出条件怎么对齐才不丢数据或多跑一轮？
这是最常踩的坑：3 行数据，循环体执行了 4 次，最后一次 FETCH 返回 NULL，但变量没被重置，导致上一轮值被重复使用。关键在「检查时机」：
-
FETCH执行后立即触发NOT FOUNDhandler，把done设为TRUE - 但如果你用
WHILE NOT done DO ... FETCH ... END WHILE，就会在done = TRUE后仍进入循环体一次（因为判断发生在循环头，而FETCH在循环尾） - 正确结构是
LOOP+FETCH+IF done THEN LEAVE，确保FETCH后立刻检查、立刻退出
示例片段（不可用于函数，仅限 PROCEDURE）：
DECLARE done INT DEFAULT FALSE; DECLARE v_id BIGINT; DECLARE v_amount DECIMAL(10,2); DECLARE cur CURSOR FOR SELECT id, amount FROM orders WHERE status = 'pending'; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; <p>OPEN cur; read_loop: LOOP FETCH cur INTO v_id, v_amount; IF done THEN LEAVE read_loop; END IF; -- 此处处理 v_id, v_amount，比如 INSERT INTO settle_log ... END LOOP; CLOSE cur;
真正复杂的地方不在语法，而在于：你得接受「MySQL 函数天生不支持逐行状态机」这个事实。所有想绕过它的尝试，最终都会在可维护性或一致性上付出更高代价。
