MySQL触发器禁止修改当前表，可用BEFORE触发器预计算或移至应用层；PG允许AFTER更新但需防死循环；批量操作绕过触发器，冗余字段应权衡一致性与维护成本。
触发器里改同一张表会报错 ERROR 1442
MySQL 不允许在触发器中直接修改当前正在被操作的表，这是硬性限制。比如在 orders 表的 AFTER INSERT 触发器里再执行 UPDATE orders，就会触发 ERROR 1442 —— 即使你只是想更新某几个冗余字段。
绕过方式只有两个：要么用存储过程+延后执行（不推荐），要么把反向填充逻辑挪到应用层或用 BEFORE 触发器预计算值。
-
BEFORE INSERT/UPDATE是安全的，可直接赋值给NEW.xxx字段 - 如果冗余字段依赖其他表（如用户昵称来自
users表），BEFORE触发器里能用(SELECT nickname FROM users WHERE id = NEW.user_id)查一次，但要注意 NULL 和性能 - 避免在触发器里写复杂子查询或 JOIN，MySQL 触发器不支持多表
UPDATE，也容易锁表
PostgreSQL 的 AFTER 触发器可以安全更新原表
PG 没有 MySQL 那套限制，AFTER 触发器里对原表做 UPDATE 是允许的，但得小心死循环——比如触发器自己又触发了另一个同类型的触发器。
典型做法是加一个标记字段或用 pg_trigger_depth() 控制递归深度：
IF pg_trigger_depth() > 1 THEN RETURN; END IF;
- 务必在
UPDATE条件里加上WHERE ctid = OLD.ctid或主键条件，避免误更新整张表 - 如果冗余字段要聚合多个子记录（如订单总金额），别在触发器里查子表并求和，先用物化视图或异步任务更稳
- PG 触发器函数返回
NULL会跳过后续操作，返回OLD或NEW才生效，这点容易写错
触发器无法处理批量导入或 LOAD DATA INFILE
MySQL 的 LOAD DATA INFILE 和大多数 ORM 的批量插入（如 Django 的 bulk_create、SQLAlchemy 的 bulk_insert_mappings）默认绕过触发器——不是 bug，是设计如此。
- MySQL 8.0+ 的
LOAD DATA可通过SET FOREIGN_KEY_CHECKS=0等方式间接触发，但不可靠，建议导完后补跑一次更新脚本 - 应用层批量写入时，必须显式调用填充逻辑，不能依赖触发器“自动”发生
- 如果业务允许，把冗余字段改成生成列（
GENERATED ALWAYS AS）更省心，但只支持确定性表达式，不能查其他表
冗余字段更新时机错位导致数据不一致
最隐蔽的问题不是触发器写不写得出来，而是“什么时候该更新”。比如用户改了昵称，但订单表里的 buyer_nickname 并没跟着变——因为触发器只监听订单表的变更，不监听用户表。
反向填充本质是跨表同步，触发器天然只响应本表事件。所以：
- 单向填充（A → B）用 A 表的触发器没问题；双向或跨表填充（A ↔ B），得在两边都建触发器，且必须约定好谁“主”谁“从”
- 如果用户昵称允许随时改，订单冗余字段就该设为“快照”，即插入时固化，之后永不更新——否则一致性维护成本远超收益
- 真要强一致，不如去掉冗余字段，用
JOIN或物化视图；非要冗余，就接受它“最终一致”，用消息队列异步修正
触发器不是银弹，它只解决“本表变更时顺手填一下”的场景。一旦涉及多表、批量、历史数据或高并发，边界立刻模糊——这时候该问的不是“怎么写触发器”，而是“为什么非得冗余”。
