触发器不能修复脏数据，必须分“离线批量修正+在线实时拦截”两步；禁止在AFTER触发器中UPDATE修数据，否则易致回滚、死锁或数据不一致。
触发器不能用来“修复”已存在的脏数据，它只响应未来的 DML 操作；所谓“补丁逻辑”，必须拆成两部分：离线批量修正 + 在线实时拦截，否则会掩盖问题或引发死锁。
触发器里写UPDATE语句修数据？别这么干
很多人想在 AFTER UPDATE 触发器里加一段 UPDATE target_table SET ... WHERE id = NEW.id 来“自动修正”，这看似省事，实则埋雷：
- 如果修正逻辑本身出错（比如字段类型不匹配、违反外键），整个原始
UPDATE会回滚——但用户根本不知道是哪条规则拦住了他 - 若修正语句又触发其他表的触发器，极易形成隐式递归（MySQL 直接报
ERROR 1442） - 修正操作和原始操作共享同一事务，一旦耗时长，会拖慢主业务链路，尤其在高并发更新同一行时
- 最危险的是：你修了 A 表，但 B 表还没来得及同步更新，中间态暴露给应用层
真正可行的“补丁逻辑”分两步走
一致性修复不是靠一个触发器兜底，而是靠“离线清洗 + 在线拦截”双轨并行：
-
离线清洗：用带
FOR UPDATE的分页脚本，按业务主键+时间范围抽样扫描，生成UPDATE ... SET ... WHERE id IN (...)批量语句，在低峰期执行。例如：SELECT id, amount, status FROM orders WHERE created_at > '2026-03-01' AND (amount
-
在线拦截：在
BEFORE INSERT/UPDATE中用SIGNAL SQLSTATE '45000'阻断非法值，而不是偷偷改掉它。例如禁止负金额：IF NEW.amount
- 修复脚本必须加锁且停写入：一边跑
UPDATE JOIN，一边有应用持续写入，刚修好的记录可能立刻被新逻辑覆盖
哪些场景适合触发器做“轻量同步”，哪些必须绕开
触发器只适合做无副作用、幂等、单向、低延迟的派生字段维护，超出这个范围就该换方案：
- ✅ 适合：
BEFORE INSERT填充created_at或标准化手机号格式；AFTER INSERT更新关联统计数（如订单数+1），且目标表只读或无其他写入路径 - ❌ 不适合：跨库同步、调用外部 HTTP、解析 JSON 字段、查大表做判断、重算全量聚合值（如“所有未发货订单总金额”）
- ⚠️ 容易踩坑：用
SELECT ... FOR UPDATE锁汇总行时没加WHERE条件，导致锁整张表；或在BEFORE UPDATE中修改NEW.col后又让应用层二次赋值，造成逻辑冲突
最常被忽略的一点：触发器没有“执行历史”可查。一旦上线，它就静默运行，直到某天某条数据异常暴露问题。所以任何触发器都必须配监控——记录每次执行耗时、失败率、影响行数，否则等于在生产环境埋了个定时炸弹。
