应主动校验而非依赖触发器报错，通过分片抽样比对派生字段发现静默失败；补偿须异步闭环，避免死锁与阻塞；补偿执行需加锁、限范围、验结果；主从补偿须确保row模式并规避非确定性函数。
触发器同步失败后数据不一致怎么发现
靠错误日志或应用报错来发现同步失败，基本等于等出事。真正危险的是“静默失败”：主表写入成功，关联表没更新，但没有任何提示。
典型表现包括：INSERT后审计字段为NULL或默认值、UPDATE后统计数没变、DELETE后子表记录残留。这些都不是数据库报错，而是数据状态错位。
必须主动校验，不能依赖触发器“自己报错”。实操建议：
- 对关键业务表建立校验脚本，按
created_at+status+ 主键分片抽样，避免全表扫描 - 校验目标不是
COUNT(*)，而是逐行比对派生字段（如user_order_count是否等于(SELECT COUNT(*) FROM orders WHERE user_id = t.id)） - 把校验结果写入独立的
consistency_check_log表，带check_time和diff_detail字段，方便回溯
补偿逻辑为什么不能写在触发器里
很多人想在AFTER UPDATE触发器里补一句UPDATE summary_table SET count = (SELECT COUNT(*) FROM ...)，这会立刻引发死锁或递归调用。
MySQL 明确禁止在触发器中修改触发它的表，PostgreSQL 虽允许但极易因SELECT FOR UPDATE导致阻塞。更严重的是：补偿操作和原始操作共享同一事务，一旦慢查询卡住，整个业务链路就拖垮。
正确做法是把补偿从触发器剥离，走异步闭环：
- 触发器只负责往
tx_outbox表插入一条记录，含table_name、row_id、operation、created_at - 独立服务轮询
tx_outbox，按created_at排序消费，执行补偿逻辑并标记processed = 1 - 补偿失败时写入
compensation_failure_log，支持人工介入或自动重试（最多3次）
补偿脚本执行时怎么避免被覆盖
一边跑补偿UPDATE JOIN，一边应用还在持续写入，刚修好的记录可能立刻被新逻辑覆盖——这是最常被忽略的并发风险。
补偿不是“再跑一遍SQL”，而是要控制写入窗口：
- 补偿前先停写入：用
FLUSH TABLES WITH READ LOCK（MySQL）或pg_advisory_lock（PostgreSQL）锁定关键表 - 补偿语句必须加
WHERE id IN (...)且配合FOR UPDATE，防止其他事务修改同一行 - 修复范围严格限定在本次校验发现的异常ID集合，不要用模糊条件（如
WHERE status = 'pending'） - 执行完立刻释放锁，并验证修复结果（比如查
summary_table对应行是否更新）
主从复制环境下补偿要额外注意什么
如果用了binlog_format = STATEMENT，触发器在从库根本不会执行，补偿脚本在主库跑完，从库数据还是旧的——等于白干。
必须确认复制模式已切到ROW，且满足四个硬性条件：binlog_format=ROW已在主从都生效、无SET SQL_LOG_BIN=0语句、slave_exec_mode=STRICT、所有新连接已加载配置。
即便开了ROW，也要避开三类危险函数：NOW()、UUID()、@user_var。它们在从库执行结果不可控，补偿脚本里得用确定性值替代。
最后一步：主库插入一条测试数据触发同步，然后手动比对主从所有被影响的表字段，不能只看Seconds_Behind_Master。
