触发器不能替代应用层逻辑实现可靠自动更新——仅适用于单表、低频、可预判场景；高频写入、批量操作、跨库同步及强一致性需求必须绕开触发器，优先采用应用层显式事务+幂等设计。
触发器不能替代应用层逻辑来实现“可靠”的数据自动更新——它只在单表、低频、可预判的场景下可用；高频写入、批量操作、跨库同步、强一致性要求，都得绕开触发器。
BEFORE UPDATE 是唯一安全写冗余字段的地方
MySQL 中 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同样跳过触发器，哪怕有唯一键冲突也静默忽略 - 想覆盖这个行为，只能把批量逻辑拆成单行 + 显式事务，或改用应用层异步任务兜底
- SQL Server 的
INSTEAD OF触发器能拦截批量插入，但需手动解析INSERTED表并重写逻辑，复杂度陡增
跨表同步别信“自动”，得靠显式事务+幂等设计
触发器无法回滚调用它的主事务。比如主表 UPDATE 失败了，但触发器已成功修改了另一张表，数据就处于不一致状态。
- 所有数据库都绕不开的盲区：触发器本身不是分布式事务协调者，也不能保证跨表原子性
- 真正可靠的同步路径是：应用层显式开启事务 → 更新主表 → 更新关联表 → 统一提交；失败则整体回滚
- 如果必须用触发器做轻量同步，务必在目标表上加唯一约束 + 使用
INSERT ... ON CONFLICT DO UPDATE（PG）或INSERT IGNORE（MySQL）实现幂等
最常被忽略的一点：触发器函数体里漏写 RETURN NEW（PG）或误用 SELECT 查询当前表（MySQL），都会让整个 DML 操作失败或静默丢弃——它不像应用代码那样有明确报错路径，问题往往在线上压测或高并发时才暴露。
