MySQL触发器中不支持游标及循环语句，因其设计初衷是响应单行DML操作；需批量处理时应改用存储过程、应用层逻辑或中间表+事件调度。
MySQL触发器里根本不能用游标
直接说结论：MySQL 的 TRIGGER 中不支持声明 CURSOR，也不允许使用 LOOP、WHILE 或 REPEAT 这类流程控制语句。这是语法层面的硬性限制，不是写法不对或版本太低的问题。
触发器设计初衷是响应单行 DML（INSERT/UPDATE/DELETE），它天然以“行级”为单位执行——每次只作用于被修改的那一行（或新旧行对）。所以 MySQL 不提供、也不鼓励你在触发器里做批量扫描、循环遍历或跨行聚合这类操作。
为什么有人误以为能用游标？常见混淆来源
容易搞混的地方在于：MySQL 存储过程（PROCEDURE）和函数（FUNCTION）确实支持 CURSOR + LOOP，但触发器（TRIGGER）是独立语法域，二者不能混用。
- 把存储过程里的写法直接复制进触发器定义，会报错：
ERROR 1064 (42000): You have an error in your SQL syntax...，错误位置往往在DECLARE CURSOR或OPEN关键字上 - 某些 ORM 或可视化工具生成的“伪代码”可能模糊了过程与触发器边界，导致误解
- MySQL 8.0+ 支持 CTE 和窗口函数，但依然没放开触发器内的循环能力
替代方案：想在数据变更时批量处理，该怎么做？
如果业务逻辑确实需要“某次插入后，批量更新关联表的 N 条记录”，触发器不是正确载体。应把逻辑外移到应用层或定时任务中，或改用以下方式：
- 用
AFTER INSERT触发器仅记录关键信息（如主键、时间戳）到一张中间表（例如pending_tasks），再由外部脚本或事件调度器（EVENT）定期消费并用存储过程处理 - 在应用代码中，把原“单条插入 + 循环更新”合并为一条带子查询的
UPDATE，例如：UPDATE t2 SET status = 'processed' WHERE id IN (SELECT ref_id FROM t1 WHERE created_at > NOW() - INTERVAL 1 MINUTE) - 如果必须强一致性且数据量小，可考虑在触发器里用多条独立
UPDATE语句硬编码匹配条件（但无法动态遍历结果集）
真正能用游标的场景：改用存储过程
如果你只是想实现“查一批数据 → 循环处理 → 更新/插入”，请明确改用 PROCEDURE，而不是强行塞进触发器。一个最小可用示例：
DELIMITER $$ CREATE PROCEDURE process_orders() BEGIN DECLARE done INT DEFAULT FALSE; DECLARE v_order_id INT; DECLARE cur CURSOR FOR SELECT id FROM orders WHERE status = 'pending'; DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE; <p>OPEN cur; read_loop: LOOP FETCH cur INTO v_order_id; IF done THEN LEAVE read_loop; END IF; UPDATE orders SET status = 'processed' WHERE id = v_order_id; END LOOP; CLOSE cur; END$$ DELIMITER ;
调用它：CALL process_orders();。注意：这个过程不能在触发器内部调用，也不能由触发器自动触发——否则仍会违反限制。
真正麻烦的点不在语法，而在于混淆了“响应式动作”和“批处理任务”的职责边界。MySQL 的触发器机制非常克制，越早接受这个事实，越少掉进语法报错和逻辑错乱的坑里。
