触发器中使用游标通常是错误的，因mysql的for each row触发器本就按行执行，套用游标会导致死锁、性能雪崩，95%场景可用集合操作替代。
触发器里用游标通常就是错的
MySQL 的 FOR EACH ROW 触发器天然按行执行，再套一层游标遍历同一张表，等于把单行逻辑硬拖成循环，不仅违反设计本意，还极易引发死锁或性能雪崩。真实场景中，95% 带游标的触发器都可以用集合操作替代。
先确认是否真需要游标
常见误判场景包括：想在 AFTER INSERT 中批量更新关联表、想统计新插入数据的聚合值、想根据多行结果做条件判断。这些其实都能避开游标：
- 用
INSERT ... SELECT或UPDATE ... JOIN替代逐行更新 - 聚合计算改用子查询或临时变量，例如：
SELECT AVG(score) INTO @avg_score FROM student; - 条件判断移到应用层或用
CASE WHEN+ 窗口函数（MySQL 8.0+） - 若必须逐行处理，优先考虑事件调度器（
EVENT）或应用定时任务，而非卡在事务内
非用不可时的最小化写法
如果业务强约束必须用游标（比如调用外部存储过程、依赖顺序执行），务必遵守三原则：声明位置严格、结束条件显式、关闭动作不可省略。
-
DECLARE必须紧贴BEGIN后，且变量声明在游标声明前 - 必须配
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;，否则游标走到末尾会报错中断 - 每次
FETCH后立即检查done变量，用REPEAT ... UNTIL done END REPEAT;而非WHILE（避免首次FETCH前就进入循环） - 游标只读，禁止在循环体内修改被触发表（MySQL 不允许），否则触发器直接失败
重构后仍要盯住的坑
即使语法跑通，游标在触发器里依然脆弱：
- 事务范围扩大：游标打开期间整个事务被锁定，高并发下极易阻塞其他操作
- 错误难定位：游标内部出错不会抛具体行号，只能靠
GET DIAGNOSTICS捕获，且 MySQL 5.7 以下不支持 - 无法调试：Navicat 或命令行执行触发器时，游标变量值不可见，只能靠
INSERT INTO debug_log临时表打点 - 版本兼容性：MySQL 8.0 的
WINDOW函数能替代大量游标场景，但 5.7 用户得手动降级写法
真正难的不是写对游标语法，而是判断“这里到底该不该用游标”。多数时候，删掉游标比修好它更接近正确答案。
