MySQL触发器中禁止使用游标，因语法硬限制会直接报ERROR 1064；游标仅限存储过程、函数或匿名块中使用，替代方案应优先采用集合操作、CTE窗口函数或异步消息表。
SQL触发器里用游标，基本等于主动触发性能雪崩——不是写得不够好，而是架构上就不该这么用。
MySQL触发器根本不能用游标
这不是版本兼容问题，是语法硬限制。你在触发器里写DECLARE CURSOR、OPEN cur或FETCH NEXT，MySQL 8.0+ 也会直接报ERROR 1064。复制存储过程里的游标代码进去，必然失败。
真正能用游标的地方只有：CREATE PROCEDURE、CREATE FUNCTION（注意不能含修改语句）、或交互式客户端执行的匿名块（如 MySQL Shell 的 \sql 模式）。
如果你在触发器里想“批量同步”或“逐行审计”，正确路径是：
- AFTER INSERT 触发器只往轻量中间表（如
pending_sync）插一条记录 - 配一个 EVENT 或应用层定时任务，每 30 秒跑一次存储过程，用游标处理
pending_sync并清空
SQL Server触发器支持游标但极易死循环和句柄泄漏
能用 ≠ 应该用。三个典型坑：
-
@@FETCH_STATUS在并发下不稳定；漏写IF @@FETCH_STATUS 0 BREAK，循环就卡死 - 漏写
CLOSE cur和DEALLOCATE cur，句柄持续累积，在sys.dm_exec_cursors里越积越多 - 默认
FORWARD_ONLY游标无法回退；若逻辑需要“重读当前行”，必须显式声明SCROLL，但会加重锁开销
常见错误写法中，FETCH 后没检查状态就进循环体，导致无限插入或更新。正确收尾必须包含两步：CLOSE cur 和 DEALLOCATE cur，缺一不可。
PostgreSQL触发器里用游标 = 明确反模式
PostgreSQL 不仅不鼓励，文档和社区都明确视为反模式。原因很直接：
- 触发器本身已是
FOR EACH ROW粒度，再套一层游标查子集，复杂度从 O(1) 变成 O(n²) - INSERT INTO orders 耗时可能从 2ms 涨到 800ms，且无法并行
- 游标作用域仅限当前函数调用，跨触发器实例无法复用，日志反复报
cursor "xxx" does not exist
想做逐行衍生逻辑？改用 MERGE、UPDATE FROM 或 CTE + 窗口函数。哪怕要发通知，也该写入消息表由外部消费者拉取，而不是在触发器里开游标调 API。
所有数据库共通的替代方案优先级
90% 的游标需求其实可绕过。写游标前，先快速核对这几点：
- 能否用
UPDATE ... FROM inserted（SQL Server）或UPDATE t1 JOIN inserted i ON ...（MySQL）一次性完成？ - 是否只是累计、排序、分组取 Top N？用 CTE + 窗口函数（
ROW_NUMBER(),SUM() OVER）更稳更快 - 是否因内存或网络压力才想“逐行”？那游标该放在应用层——用
fetchSize（JDBC）或SqlDataReader.Read()（.NET）流式读取处理 - 是否涉及外部调用（发短信、写日志）？触发器里绝不能同步做，必须解耦为写队列表 + 异步作业
最常被忽略的一点：游标不是“慢在写法”，而是它强制把集合操作退化为迭代，天然无法利用索引合并、并行扫描、查询重写等优化器能力。一旦上线，数据量翻倍，耗时往往翻四倍以上。
