首先检查主从复制状态，确认Slave_IO_Running和Slave_SQL_Running均为Yes，Seconds_Behind_Master无持续增长，Last_Error无错误；接着使用pt-table-checksum对比主从数据一致性，发现不一致表后用pt-table-sync修复；若存在慢查询或锁等待，启用慢查询日志并结合SHOW PROCESSLIST和SHOW ENGINE INNODB STATUS分析事务回滚或死锁原因；最后审查应用逻辑，确保唯一约束存在，避免REPLACE INTO等误操作，通过SELECT GROUP BY HAVING COUNT(*) > 1排查重复数据。

在 MySQL 中排查数据一致性问题，关键在于定位异常数据、分析产生原因并验证修复结果。这类问题通常出现在主从复制环境、应用逻辑错误或并发操作中。以下是实用的排查思路和操作方法。

检查主从复制状态

如果使用了主从架构，数据不一致往往源于复制中断或延迟。

执行以下命令查看从库状态：

重点关注以下字段：

• Slave_IO_Running 和 Slave_SQL_Running：必须都为 Yes，否则复制已停止。
• Last_Error：显示最近的错误信息，如主键冲突、表不存在等。
• Seconds_Behind_Master：判断延迟时间，持续增长说明有执行卡顿。

若发现 SQL 线程报错，可结合错误码判断是否为数据冲突。例如错误日志提示“Duplicate entry”，可能是主库执行了非幂等操作导致从库无法重放。

对比主从数据内容

当复制正常但怀疑数据内容不一致时，需逐表核对。

可使用官方工具 pt-table-checksum 和 pt-table-sync（Percona Toolkit 提供）。

步骤如下：

• 在主库运行 pt-table-checksum，生成校验值：
pt-table-checksum --host=master_ip --user=root --password=xxx
• 该工具会在从库自动比对 checksum 结果，输出不一致的表。
• 确认差异后，用 pt-table-sync 生成修复语句同步数据。

若无法使用工具，可手动抽样比对关键表：

在主从分别执行，对比结果是否一致。注意 GROUP_CONCAT 有长度限制，大数据量需分段校验。

分析慢查询与锁等待

并发写入可能导致部分事务未提交或死锁回滚，引发数据缺失或重复。

启用慢查询日志，查找执行时间长或扫描行数多的语句：

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;

结合 SHOW PROCESSLIST 查看当前运行的线程，关注处于 “Sending data”、“Locked” 状态的查询。

进一步检查 InnoDB 状态：

在输出中查找 “TRANSACTIONS” 和 “LATEST DETECTED DEADLOCK” 部分，分析是否有频繁回滚或死锁记录。

检查应用层逻辑与唯一约束

很多数据不一致源自应用代码缺陷，如未处理异常、重复提交、绕过主键校验等。

建议：

• 确认关键表是否有合理索引，尤其是主键和唯一键。缺失唯一约束容易导致重复数据。
• 审查业务代码中涉及写操作的部分，确保事务边界正确，避免中间状态被其他会话读取。
• 检查是否使用了 REPLACE INTO 或 INSERT IGNORE，这类语句可能意外修改已有数据。

可通过查询疑似重复数据辅助判断：

基本上就这些。重点是先判断问题范围——是全局复制异常还是局部数据错误，再选择对应手段。工具能提效，但理解原理才能根治问题。