触发器中使用游标是性能雷区，SQL Server易致死循环和句柄泄漏，MySQL语法硬限制不支持，PostgreSQL视为反模式；唯一合理场景是临时调试或极小批量强一致性操作。
触发器里用游标处理多行数据，基本等于主动给自己埋性能雷——除非你清楚知道为什么非用不可，否则立刻停手。
SQL Server 中游标能用，但必须绕开几个致命坑
SQL Server 的触发器确实支持 CURSOR，但实际落地时容易踩三个硬伤：
-
@@FETCH_STATUS在并发场景下可能不稳定，不加IF @@FETCH_STATUS <> 0 BREAK容易进死循环 - 漏写
CLOSE或DEALLOCATE会导致游标句柄泄漏，pg_stat_activity（PostgreSQL）或sys.dm_exec_cursors（SQL Server）里会越积越多 - 游标默认是
FORWARD_ONLY，不能回退；若逻辑中需要“重读当前行”，得显式声明SCROLL，但会加重锁开销
示例中常见错误写法：
DECLARE cur CURSOR FOR SELECT id, name FROM inserted;<br>OPEN cur;<br>FETCH NEXT FROM cur INTO @id, @name;<br>WHILE @@FETCH_STATUS = 0<br>BEGIN<br> -- 这里没检查 @@FETCH_STATUS 是否为 -1 或 -2，直接进循环<br> INSERT INTO audit_log VALUES (@id, @name);<br> FETCH NEXT FROM cur INTO @id, @name;<br>END
正确收尾必须包含：
CLOSE cur;<br>DEALLOCATE cur;
MySQL 触发器根本不能用游标
这不是版本问题，是语法硬限制：DECLARE CURSOR、OPEN、FETCH、WHILE 全部在 MySQL 触发器中报错 ERROR 1064。哪怕 MySQL 8.0+ 支持 CTE 和窗口函数，触发器仍禁止流程控制语句。
如果你复制了存储过程里的游标代码到触发器定义里，一定会失败。真正能用游标的地方只有：
- 存储过程（
CREATE PROCEDURE） - 函数（
CREATE FUNCTION，注意不能含修改语句） - 交互式客户端执行的匿名块（如 MySQL Shell 的
\sql模式）
想在数据变更后批量同步？别硬塞进触发器。改用：
- AFTER INSERT 触发器往中间表
pending_sync插一条轻量记录 - 配一个
EVENT每 30 秒跑一次存储过程，用游标处理pending_sync并清空
PostgreSQL 触发器里用游标 = 反模式
PostgreSQL 不仅不鼓励，而且明确视为反模式。原因很直接：
- 触发器本身已是
FOR EACH ROW或FOR EACH STATEMENT粒度，再套一层游标纯属冗余 - 每行触发都开一次游标查子集，复杂度从 O(1) 变成 O(n²)，
INSERT INTO orders耗时可能从 2ms 涨到 800ms - 游标作用域仅限当前函数调用，跨触发器实例无法复用，日志里反复出现
cursor "xxx" does not exist
真要维护统计值（比如用户最近 3 条订单平均金额），正确路径是：
- 触发器只做原子标记：
INSERT INTO user_avg_queue (user_id, op_type) VALUES (NEW.user_id, 'INSERT') - 用
pg_cron定期执行集合更新：UPDATE users SET recent_avg = (SELECT avg(amount) FROM orders WHERE user_id = users.id ORDER BY created_at DESC LIMIT 3) - 最后
TRUNCATE user_avg_queue
游标唯一合理存在的场景：调试与极小批量强一致性
生产环境里，游标只该出现在两个地方：
- 临时调试：在触发器里加
RAISE NOTICE打印中间结果，且必须跟PERFORM pg_sleep(0.001)防阻塞（PostgreSQL） - 数据量极小（
只要插入/更新涉及多行，就别幻想靠变量赋值（@var = col）或游标逐行兜底——它掩盖的是设计缺陷，不是解决问题。
