MySQL 数据不一致通常出现在主从复制、分布式写入、应用双写、异常中断或备份恢复等场景中。排查核心思路是：先定位不一致的表和记录，再分析产生原因，最后修复并加固机制。
一、快速识别不一致的表和行
人工比对效率低且易漏，推荐用工具辅助检测：
pt-table-checksum（Percona Toolkit）：在主库运行，生成校验和并同步到从库，通过对比 checksum 判断是否一致。注意需确保主从时间同步、binlog_format=ROW、从库无延迟积压。 mysqldbcompare（MySQL Utilities）：支持跨实例（如主从、不同集群）直接比对表结构与数据，适合离线校验，但大表会锁表或影响性能，建议在低峰期执行。 自建校验逻辑：对关键表按主键分块，计算CRC32(CONCAT(...))或
MD5(GROUP_CONCAT(... ORDER BY id))，逐块比对。适合字段少、更新不频繁的配置类表。
二、检查主从复制层面的一致性问题
主从不一致最常见，需分层验证：
确认复制状态：SHOW SLAVE STATUS\G查看
Seconds_Behind_Master、
SQL_Thread_State、
Retrieved_Gtid_Set与
Executed_Gtid_Set是否匹配。 检查跳过错误：
Slave_SQL_Running_State显示 "Has read all relay log" 但数据仍不一致，可能曾执行过
SET GLOBAL sql_slave_skip_counter=1或
gtid_next跳过事务，需翻查历史操作日志。 确认 binlog 格式与写入方式：若使用 STATEMENT 格式 + 非确定函数（如
NOW()、
UUID()、
CONNECTION_ID()），会导致主从执行结果不同；混合写入（部分直连主、部分直连从）也会绕过复制链路。
三、应用层与业务逻辑导致的隐性不一致
这类问题不会触发复制报错，但数据语义已偏离预期：
双写逻辑未加锁或未用事务包裹：例如先写 MySQL 再写 Redis，中间失败导致缓存与数据库不一致；或两个服务并发更新同一行，发生写覆盖。 本地缓存未及时失效：应用读取后缓存了旧值，后续更新未清理对应缓存，造成“读到旧数据”。可通过开启 MySQL 的general_log抽样分析实际 SQL 执行顺序来佐证。 批量操作绕过约束：用
LOAD DATA INFILE或
INSERT ... SELECT批量导入时禁用了外键/唯一索引检查（
SET FOREIGN_KEY_CHECKS=0），导致脏数据入库。
四、修复与预防建议
发现不一致后，优先保证服务可用，再择机修复：
小范围差异：用pt-table-sync自动修复（慎用于生产，务必先在测试环境验证，且确保主从角色明确、无双向写入）。 大表或复杂逻辑差异：导出主库数据，用脚本比对后生成补丁 SQL，在从库执行
REPLACE INTO或
INSERT ... ON DUPLICATE KEY UPDATE。 长期预防：启用 GTID 复制、强制 ROW 格式、关闭
sql_log_bin仅限必要维护操作、关键表增加逻辑删除标记而非物理删除、所有写操作走统一 DAO 层并记录变更日志。
不复杂但容易忽略。重点不在“怎么修”，而在“怎么早发现、不复发”。
