排查MySQL数据一致性问题，关键在于定位数据差异的来源并验证多个节点或表之间的数据是否同步。常见场景包括主从复制延迟、分库分表数据错乱、应用层双写不一致等。以下是实用的排查思路和方法。
检查主从复制状态
在主从架构中，数据不一致通常源于复制中断或延迟。通过以下命令确认复制是否正常：
SHOW SLAVE STATUS\G：查看Seconds_Behind_Master是否为0，Slave_IO_Running和Slave_SQL_Running是否为Yes。 若SQL线程报错（如1062主键冲突），说明从库写入异常，需分析Last_Error字段。 检查主从server-id是否唯一，避免环形复制或ID冲突。比对表数据一致性
当怀疑主从数据内容不一致时，可使用工具或SQL手动校验。
使用pt-table-checksum计算主库表的checksum值，并在从库比对结果，自动发现差异。 对关键表执行COUNT(*)、SUM(关键字段)等聚合查询，对比主从输出是否一致。 抽样比对具体行：SELECT * FROM table WHERE id IN (具体ID列表) ORDER BY id，逐行核对。分析binlog与relay log
当复制出错或数据丢失时，日志是定位问题的核心。
用mysqlbinlog解析主库binlog，确认变更是否正确写入。 检查从库relay-log中的事件是否与主库一致，判断是否在传输或回放阶段出错。 关注GTID或传统position是否连续，跳过事务会导致数据缺失。应用层写操作审计
有时不一致来自应用逻辑，比如未走主库写、缓存与数据库不同步。
检查应用是否误将写请求发往从库（尤其读写分离中间件配置错误）。 确认双写多个表或库时，是否使用事务保证原子性。 查看慢查询日志，是否存在长时间未提交事务导致数据“看似”不一致。基本上就这些。定期做数据校验、监控复制延迟、规范应用写入路径，能大幅降低不一致风险。发现问题后先止血（如暂停写入或切主），再修复数据。工具辅助+逻辑分析结合最有效。
