SQL触发器中使用游标必然导致严重阻塞，因其违背集合操作原则，引发O(n²)性能退化；应改用UPDATE FROM或INSERT SELECT等集合语句，或通过异步队列解耦业务逻辑。
在SQL触发器中使用游标几乎必然导致严重阻塞——这不是配置问题，而是设计层面的冲突。触发器已按行或语句粒度执行，再套一层游标等于让数据库反复做同一件事，锁时间翻倍、事务膨胀、并发能力归零。
触发器里开游标为什么会让INSERT变慢百倍
根本矛盾在于执行模型错配：触发器本身已是“逐行上下文”，FOR rec IN SELECT ... LOOP 这类写法强行把集合操作掰成N次单行调用，每次fetch都触发一次锁申请、一次日志写入、一次执行计划重编译。
- 常见错误现象：
INSERT INTO orders原本 5ms，加了游标后涨到 800ms；pg_stat_activity显示大量idle in transaction；日志里反复报cursor "cur1" does not exist - 原因不是游标语法错，而是作用域仅限当前触发器调用实例，无法复用，且每行都新建一次游标资源
- 性能影响是指数级的：1000 行插入 → 1000 次游标打开 + 1000×N 次子查询，O(n²) 就坐实了
替代方案：用UPDATE FROM或INSERT SELECT重写聚合逻辑
只要目标是“对某条件集合做更新”，就该用集合语句直接干掉游标。比如要更新用户最近3笔订单的平均金额，别在触发器里查再算，改用原子化 SQL：
UPDATE users u SET recent_avg = sub.avg_amount FROM ( SELECT user_id, avg(amount) AS avg_amount FROM orders WHERE user_id = NEW.user_id ORDER BY created_at DESC LIMIT 3 ) sub WHERE u.id = sub.user_id;
- 这个写法不依赖游标，不引入额外事务边界，InnoDB/PostgreSQL 都能走索引快速定位
- 注意必须确保
orders.user_id和created_at有联合索引，否则LIMIT 3会退化为全表扫描 - 若涉及多表关联更新，优先用
UPDATE ... FROM (SELECT ...)而非UPDATE ... JOIN，前者在 PostgreSQL 中更可控
真需要遍历处理？交给异步队列，别卡在事务里
当业务逻辑确实无法转成单条 SQL（比如要调用外部 API、发短信、写 ES），唯一安全做法是把“触发”和“执行”彻底分离：
- 触发器只做一件事：
INSERT INTO notify_queue (table_name, pk_id, op_type, created_at) VALUES ('orders', NEW.id, 'INSERT', NOW()) - 禁用所有
CALL、SELECT FOR UPDATE、跨库查询，字段只存必要 ID 和类型，表引擎用InnoDB，主键明确，不加任何冗余索引 - 用
pg_recvlogical（PG）或Canal（MySQL）监听 binlog，消费端独立部署，失败可重试、可限流、可监控积压行数
最容易被忽略的是锁生命周期——触发器内任何一次 SELECT ... WHERE status = 'pending'（没走索引）都会在 RR 隔离级别下升级为间隙锁，而另一事务正按相反顺序操作，死锁就藏在那毫秒级的时序差里。
