UPDATE src_order SET is_deleted = 1, update_time = NOW() WHERE id = 9021000;
增量同步用 id 大于上次最大 id，跑了半年。源表里软删除的 3 万多条记录，在目标端还是未删除状态。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：软删除只改 is_deleted 标志，id 不变。按 id 增量取不到这类更新，目标端的旧状态永远不会被覆盖。业务查询都带 is_deleted = 0，报表却按目标表算，数字自然对不上。
这次卡住的地方就在「自增 ID 增量同步」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。
处理上按这个顺序：增量字段换成 update_time 或者直接订阅 binlog 的 update 事件；软删除时同步刷新 update_time 保证能被捞到；目标端保留 is_deleted 字段 报表按同一口径过滤；跑一次全量回刷把历史删除状态补齐。
确认没问题再收工，回刷后目标表和源表按 is_deleted 分组的行数完全一致。