触发器不能直接用于实时对账，仅能标记主库变更起点；需配合sync_log表记录完整主键与操作类型，并通过GTID或位点对齐避免主从延迟误判，再由对账脚本比对关键字段实现可靠校验。
为什么不能直接用触发器做实时对账
触发器本身不解决对账，它只是差异捕获的起点。主库写入时触发 AFTER INSERT/UPDATE/DELETE，可以记录变更到一张 sync_log 表，但要注意：主从延迟会导致从库执行事件的时间晚于主库，如果在从库也建相同触发器，会重复记录；如果只在主库建，又无法感知从库端的异常（比如被手动改数据、复制中断后跳过错误）。所以触发器只适合标记「主库发出了什么」，不能代替校验逻辑。
-
sync_log必须包含table_name、pk_value、op_type（I/U/D）、binlog_pos（可选）和created_at - 避免在触发器里做跨库写入或调用外部服务——MySQL 5.7+ 不允许触发器内含
SELECT ... FOR UPDATE或事务控制语句 - 高频更新表上加触发器会明显拖慢写性能，建议仅对核心业务表（如
order、user_account）启用
如何让触发器日志真正可用于对账
关键不是“记下来”，而是“能对上”。从库必须能按相同主键查到对应行，并比对关键字段。因此：sync_log 的 pk_value 必须是完整主键（复合主键要拼成 JSON 或固定分隔符字符串），且对账脚本必须知道哪些字段参与校验（比如 amount、status、updated_at）。
- 对账脚本每次拉取
sync_log中created_at > ?的未处理记录，去从库查同主键行，逐字段比对 - 不要依赖
updated_at做增量过滤——主从时钟不同步或手动改时间会导致漏检 - 字段比对时注意 NULL 处理：
col1 = col2在任一为 NULL 时不成立，得写成(col1 col2) - 对账结果写入另一张
reconcile_result表，含diff_fields（JSON 字符串）、is_resolved标志位
主从延迟下怎么避免误报差异
刚写入主库的记录，可能还没复制到从库。如果对账脚本立刻去查，会得到 “从库无此记录” 的假阳性。不能靠 sleep 等待，得用复制位点或 GTID 对齐。
- 若开启 GTID，查主库
SELECT @@global.gtid_executed，再查从库SELECT @@global.gtid_executed，确保目标记录的 GTID 已包含在从库集合中再校验 - 若用 binlog 文件+pos，需在触发器写
sync_log时同时记下当前SHOW MASTER STATUS的File和Position - 更轻量的做法：对账前先查从库
SHOW SLAVE STATUS的Seconds_Behind_Master，>5 秒则跳过本轮，等下次调度
真正上线前必须验证的三个边界场景
大部分线上问题出在这三类操作上，测试时必须覆盖：
- 主库执行
UPDATE ... WHERE id IN (1,2,3)—— 触发器会触发三次，但sync_log必须保证每条变更独立可追溯，不能合并成一行 - 从库执行
SET SQL_LOG_BIN=0; UPDATE user SET status=9 WHERE id=100;—— 这种绕过复制的修改不会进sync_log，但对账脚本能发现数据不一致，此时要能区分是“主库没发”还是“从库被篡改” - 主库删了一行，从库因唯一键冲突卡住复制，DBA 手动
SET GLOBAL sql_slave_skip_counter = 1跳过 —— 对账会发现该主键在从库仍存在，但sync_log有 DELETE 记录，这就是明确的复制异常信号
触发器只是把变更“打个戳”，对账是否可靠，取决于你如何定义“一致”、怎么应对复制断层、以及能否快速定位是同步问题还是人为干预。别让 sync_log 成为新单点故障源——它自己也得主从同步，且定期归档清理。
