排查MySQL数据一致性问题需先定位差异来源。1. 检查主从复制状态：通过SHOW SLAVE STATUS\G确认Seconds_Behind_Master为0且Slave_IO_Running、Slave_SQL_Running为Yes，分析Last_Error及server-id配置。2. 比对表数据一致性：使用pt-table-checksum工具或执行COUNT(*)、SUM()聚合查询对比主从数据，抽样逐行核对关键记录。3. 分析binlog与relay log：用mysqlbinlog解析主库binlog，验证变更是否写入，并比对从库relay-log事件，检查GTID或position连续性。4. 审计应用层写操作：排查写请求误发从库、双写未用事务、缓存不同步等问题，结合慢查询日志识别长事务。定期校验数据、监控复制延迟、规范写入路径可降低风险，发现问题应先止血再修复，结合工具与逻辑分析高效定位。
排查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是否连续，跳过事务会导致数据缺失。
应用层写操作审计
有时不一致来自应用逻辑，比如未走主库写、缓存与数据库不同步。
- 检查应用是否误将写请求发往从库（尤其读写分离中间件配置错误）。
- 确认双写多个表或库时，是否使用事务保证原子性。
- 查看慢查询日志，是否存在长时间未提交事务导致数据“看似”不一致。
基本上就这些。定期做数据校验、监控复制延迟、规范应用写入路径，能大幅降低不一致风险。发现问题后先止血（如暂停写入或切主），再修复数据。工具辅助+逻辑分析结合最有效。
