不能靠触发器保证冗余字段强一致性，仅适用于低频、简单、可预判场景；高频写入、批量操作、跨表聚合必须移出触发器；mysql中仅before update可安全赋值new字段，after update更新原表会报error 1442。
不能靠触发器“自动更新冗余字段”来保证强一致性——它只适合低频、简单、可预判的同步场景；高频写入、批量操作、跨表聚合类需求，必须移出触发器。
MySQL 中 BEFORE UPDATE 是唯一安全写冗余字段的地方
在 AFTER UPDATE 里对原表再执行 UPDATE 会直接触发 ERROR 1442；BEFORE UPDATE 却能直接赋值给 NEW.xxx 字段，且不违反限制。
- 适用场景：用户昵称变更时，同步更新订单表里的
buyer_nickname字段（仅当该字段确实依赖主表） - 必须逐字段比对：
IF OLD.nickname != NEW.nickname THEN SET NEW.buyer_nickname = NEW.nickname;，否则无差别更新会导致冗余数据膨胀 - 注意
NULL比较：用IF NOT (OLD.nickname NEW.nickname)更稳妥，避免NULL != NULL返回FALSE - 别在
BEFORE里查其他大表——子查询若没索引，高并发下会拖慢主表写入
PostgreSQL 的 AFTER 触发器能改原表，但死循环风险极高
PG 允许在 AFTER UPDATE 中执行 UPDATE target_table SET ... WHERE id = OLD.id，但必须主动防递归，否则一次更新可能触发自身 N 次。
- 必加防护：
IF pg_trigger_depth() > 1 THEN RETURN; -
WHERE条件必须精确到行：WHERE ctid = OLD.ctid或WHERE id = OLD.id AND updated_at = OLD.updated_at，避免误更新整张表 - 触发器函数返回
NULL会跳过后续操作，返回OLD或NEW才生效，这点极易写错
所有数据库都绕不开的批量操作盲区
LOAD DATA INFILE、INSERT INTO ... VALUES (), ()、ORM 的 bulk_create 等批量写入方式，默认不触发任何触发器——这不是 bug，是设计如此。
-
MySQL的INSERT IGNORE和REPLACE INTO同样跳过触发器，哪怕有唯一键冲突也静默忽略 - 想覆盖这个行为，只能把批量逻辑拆成单行 + 显式事务，或改用应用层异步任务兜底
- Supabase 的
auth.users表插入不受你控制，但它的on_auth_user_created钩子可触发函数，这是比触发器更可靠的同步入口
跨表同步别信“自动”，得靠显式事务+幂等设计
触发器无法回滚调用它的主事务。比如主表 UPDATE（发布时间是2026年6月25日），而触发器中更新失败，主表变更已提交，冗余字段却没同步——这种错位才是最要命的。
- 触发器天然只响应本表事件，不监听源表变更。用户改了昵称，订单表里的
buyer_nickname没变，往往是因为触发器只挂在订单表上 - 反向填充本质是跨表同步，必须在源表（如
users）上建触发器，而不是目标表（如orders） - 多语言字段同步时，别用
INSERT INTO langs SELECT ... FROM main——事务未提交前，SELECT可能查不到刚插入的NEW.id，改用BEFORE预生成或硬编码默认值
真正难的不是写触发器语法，而是判断“哪张表该挂哪个事件”“哪些字段真需要同步”“批量导入后要不要补跑”——这些决策点一旦漏掉，数据不一致就藏在生产环境里，等你查日志时才冒头。
