我们搭了主从同步，有时候主库删了数据，从库居然没删掉，两边就对不上了。这种情况你们一般怎么查？

这个问题一般别先怀疑“删库没成功”，大多数时候是同步链路某个环节没完整执行，或者从库那边把这条 delete 给“漏掉了 / 卡住了 / 跳过了”。

我们这边如果碰到 主库删了、从库没删，通常会按这几个方向查，基本都能慢慢缩小范围。

先看是不是“偶发一两条”，还是“某一段时间都没同步”

这个很关键。
如果只是个别数据对不上，往往更像：

主键不规范，导致 delete 在从库匹配不到

同步条件不完整

某些特殊 SQL / 批量删除语句没有正确回放

从库之前已经脏数据了，后面越跑越偏

如果是一段时间内删的数据都没过去，那更像：

同步线程延迟或中断

binlog / 日志解析异常

从库 apply 失败后卡住

某些错误被跳过了，但没及时发现

我一般第一步先查这几个
1）先确认主库的删除到底有没有真的提交

别只看业务侧说“已经删了”，最好直接去主库确认：

这条数据现在主库是不是确实没了

删除发生的大概时间点

是单条 delete，还是批量 delete

是直接 delete，还是程序先更新状态、再异步删

事务是不是提交成功了

有时候看起来像“主库删了”，其实是业务层做了逻辑删除，或者事务回滚了，这种先排除掉。

2）看同步日志里这段时间有没有报错

这个是最常见的。
重点看删除发生那个时间点附近：

同步进程有没有报错

有没有 relay/apply 失败

有没有 duplicate key / 找不到记录 / 类型转换异常

有没有线程重启、断连、重试

很多场景其实不是 delete 没传过去，而是 从库执行到这里报错卡住了，后面的同步可能也都受影响。

3）看主从延迟

有时候不是“没删”，只是“还没同步到”。
尤其如果当时正好：

批量导数

大事务

跑报表

磁盘 IO 高

网络抖动

从库可能会明显延迟。
所以要先确认：

从库同步线程是不是正常

延迟大不大

删除发生时是不是有堆积

比较容易被忽略的几个点
1）主键或唯一键问题

这个真的很常见。
如果表设计不规范，没有稳定主键，或者同步回放 delete 时定位条件不够精确，就可能出现：

主库删掉了目标行

从库因为数据已经有偏差，根本匹配不到那一行

最终 delete 执行了，但影响行数是 0

这种情况表面看像“delete 没同步”，本质上是 主从数据早就不一致了。

2）从库有人写入过

如果从库不是严格只读，或者有人手工改过数据，那也容易出这个问题。
比如主库删的是 id=100 这条，但从库这条记录已经被改过、补过、甚至重复插入过，那同步 delete 过来未必能按预期生效。

所以这种问题一出来，我一般都会顺手排查：

从库有没有开放写入

有没有人工修数

有没有定时任务直接连从库写数据

3）批量删除 / 大事务

如果主库做的是大批量 delete，或者一个事务里改了很多数据，同步链路有时候会更容易出问题，比如：

日志传输慢

应用线程卡住

中间异常重试后部分没处理好

这种场景尤其要看那段时间的同步状态和资源占用。

真正排查时，我一般这么落地
第一层：先定点

拿一条具体对不上的数据，确认：

主库什么时候删的

从库现在还在不在

这条数据对应表有没有主键

那个时间点同步是否正常

第二层：看链路

查删除时间点附近的：

主库日志

同步组件日志

从库执行日志

是否有报错、跳过、延迟、重连

第三层：查范围

再看这是：

单表问题

单节点问题

某个时间窗口问题

还是全局偶发问题

这个判断很重要，因为它决定你后面是修一条数据，还是修整个同步机制。

如果已经对不上了，一般怎么处理

这就看你们现场要求了。

少量数据：通常先人工校正

某一批次明显丢了：把这段数据重新补同步

长期有漂移：要做主从一致性校验，必要时重建从库或重做初始化

如果只是补那几条，不去找根因，后面大概率还会继续出现。

我个人经验里最该优先关注的

按概率排的话，我一般优先怀疑这几个：

同步线程有异常，但告警没打出来

从库本身已有脏数据，delete 匹配不到

表没有合适主键/唯一键

从库被人写过

大事务或批量删除导致同步异常/延迟

标记下

看看啦。