首先检查主从复制状态，确认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 中排查数据一致性问题，关键在于定位异常数据、分析产生原因并验证修复结果。这类问题通常出现在主从复制环境、应用逻辑错误或并发操作中。以下是实用的排查思路和操作方法。
检查主从复制状态
如果使用了主从架构，数据不一致往往源于复制中断或延迟。
执行以下命令查看从库状态：
SHOW SLAVE STATUS\G重点关注以下字段：
- 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 生成修复语句同步数据。
若无法使用工具，可手动抽样比对关键表：
SELECT COUNT(*), SUM(id), MD5(GROUP_CONCAT(id ORDER BY id)) FROM tbl_name;在主从分别执行，对比结果是否一致。注意 GROUP_CONCAT 有长度限制，大数据量需分段校验。
分析慢查询与锁等待
并发写入可能导致部分事务未提交或死锁回滚，引发数据缺失或重复。
启用慢查询日志，查找执行时间长或扫描行数多的语句：
SET GLOBAL slow_query_log = ON;SET GLOBAL long_query_time = 1;
结合 SHOW PROCESSLIST 查看当前运行的线程，关注处于 “Sending data”、“Locked” 状态的查询。
进一步检查 InnoDB 状态：
SHOW ENGINE INNODB STATUS\G在输出中查找 “TRANSACTIONS” 和 “LATEST DETECTED DEADLOCK” 部分，分析是否有频繁回滚或死锁记录。
检查应用层逻辑与唯一约束
很多数据不一致源自应用代码缺陷，如未处理异常、重复提交、绕过主键校验等。
建议：
- 确认关键表是否有合理索引，尤其是主键和唯一键。缺失唯一约束容易导致重复数据。
- 审查业务代码中涉及写操作的部分，确保事务边界正确，避免中间状态被其他会话读取。
- 检查是否使用了 REPLACE INTO 或 INSERT IGNORE，这类语句可能意外修改已有数据。
可通过查询疑似重复数据辅助判断：
SELECT col, COUNT(*) FROM tbl GROUP BY col HAVING COUNT(*) > 1;基本上就这些。重点是先判断问题范围——是全局复制异常还是局部数据错误，再选择对应手段。工具能提效，但理解原理才能根治问题。
