MySQL主从架构在线上十分普遍，但网络抖动、大事务阻塞或者人为在从库误写，都会让主从数据逐渐偏离。当应用程序开始读到过期甚至错误的数据时，问题往往已经影响了业务。排查这类故障不能只盯住复制线程状态，还需要从数据本身出发做一致性校验。
一、先确认复制链路是否真的健康
很多人一看到数据不对就直接去比对表，其实第一步应该排除复制中断或严重延迟。通过执行show slave statusG，重点看Slave_IO_Running与Slave_SQL_Running是否均为Yes，以及Seconds_Behind_Master的数值。如果SQL线程正在报错，比如重复主键或者找不到记录，那明显是复制已经断了，需要先解决错误位点。
但即便两个线程都是Yes，Seconds_Behind_Master显示为0，也不代表数据一定一致。该值基于从库回放事件的原始时间戳计算，若主库曾经有过长事务或者从库并行回放存在特殊调度，仍可能出现逻辑层面的偏差。因此链路正常只是前提，不是结论。
二、使用pt-table-checksum做分块校验
Percona Toolkit里的pt-table-checksum是最常用的离线一致性检查工具。它的原理是在主库把每张表按主键或唯一索引切成多个块，对每块计算CRC32校验和，并通过复制传到从库执行相同计算，最后比对主从同一块的checksum值。这样只传输极小的哈希结果，对线上压力很小。
使用方式通常如下，注意工具需要在主库执行，并通过DSN指向从库：
# 在主库服务器执行，user需有相应权限 pt-table-checksum --host=127.0.0.1 --user=checksum --password=pass --databases=order_db --tables=orders,order_item --recursion-method=hosts --no-check-binlog-format
命令运行后，结果会写入percona.checksums表。若某行记录的master_cnt与slave_cnt不同，或checksum值不匹配，就说明该分块数据不一致。此时可以缩小到具体表，再结合业务日志判断是哪段时间写入出现了问题。
三、用pt-table-sync生成修复语句
定位到不一致表后，不要直接在从库改数据，那样会破坏复制逻辑。pt-table-sync可以先打印出修复用的SQL，确认无误后再执行。它默认会连接主库和从库，计算出使从库追上主库所需的replace或delete语句。
# 只打印修复SQL，不实际执行 pt-table-sync --print --sync-to-master h=从库IP,P=3306,u=root,p=pass --databases=order_db --tables=orders
确认输出语句合理后，去掉--print加上--execute即可在主库端执行，由复制自然同步到从库。需要提醒的是，如果表没有可靠的主键或唯一索引，pt-table-sync可能无法安全定位行，因此设计规范里必须保证每张表都有此类约束。
四、容易被忽略的误判因素
有些场景下校验和差异并不代表真实业务数据错误。例如主从的binlog_format不一致，或者从库设置了replicate_wild_ignore_table过滤了部分表，都会让校验工具产生错觉。另外若表中使用了UUID、NOW()这类非确定性函数，在基于语句的复制下也可能引起行内容不同。
还有一点是自增主键的偏差。主库批量插入后自增游标与从库可能因为并行回放而不同，但这通常不影响业务查询。排查时应优先关注业务字段，而非单纯对比auto_increment值。建立定期校验任务，并结合监控告警，才能把不一致风险控制在可接受范围内。
五、小结
MySQL数据不一致排查是一条从复制状态到行级校验的链路。先用状态命令排除明显中断，再用pt-table-checksum量化差异，最后用pt-table-sync谨慎修复。整个过程应尽量在低峰期进行，并且所有修复动作都通过主库完成，避免人为制造新的复制冲突。