MySQL 主从不一致需先定位再安全修复：用 pt-table-checksum 等工具精准识别差异，区分延迟、SQL 错误、绕过写入等类型采取对应策略，修复须幂等、分批、可回滚，长期需 ROW 格式复制、read_only 防护及定期校验。
主从数据不一致是 MySQL 高可用架构 中常见但必须快速定位和修复的问题。核心思路是：先确认不一致范围，再选择安全、可逆、低影响的方式修复，避免直接写从库或停业务。
一、快速定位不一致的表和记录
不能靠肉眼比对，要用 工具 或 SQL 精准识别差异：
- 用 pt-table-checksum（Percona Toolkit）在主库执行校验，结果会写入 checksum 表，再用 pt-table-sync –print 在从库上生成修复 SQL（不执行），确认逻辑是否合理
- 若无法装第三方工具，可对关键表用 CHECKSUM TABLE t1 对比主从结果（仅适用于无写入、小表；注意该命令在 8.0+ 中已弃用，建议改用 SELECT MD5(CONCAT(…)) 拼接关键字段哈希）
- 时间戳字段 + 自增主键组合查询，例如：SELECT id, updated_at FROM order WHERE updated_at > ‘2024-06-01’ ORDER BY id LIMIT 1000，分别在主从执行并逐行比对
二、区分不一致类型，选择对应修复策略
不是所有不一致都该“修”，要先判断成因：
- 从库延迟导致的临时不一致：查 SHOW SLAVE STATUSG 中 Seconds_Behind_Master 和 Exec_Master_Log_Pos 是否持续增长。此时只需等待追平，勿人工干预
- SQL 线程报错跳过（如 duplicate key、no such row）：检查 Slave_SQL_Running_State 和错误日志。这类需人工核对缺失 / 多余数据，再决定补插、删行或更新
- 主库被绕过写入（应用直连从库、误操作）：重点审计应用配置与 DBA 操作记录。修复前先备份从库对应表，再用主库数据覆盖
三、安全修复的实操要点
修复动作必须可控、可回滚、最小化影响：
- 禁止在从库执行 SET sql_log_bin=0 后写数据——这会导致后续主从复制断裂，且无法审计
- 推荐方式：在主库构造补偿 SQL（如 INSERT … ON DUPLICATE KEY UPDATE 或 REPLACE INTO），让其自然同步到从库。确保语句幂等
- 大表修复时，分批次操作。例如按主键范围：WHERE id BETWEEN 10000 AND 19999，每次修复后验证从库同步状态
- 修复前后，对涉及表执行 FLUSH TABLES WITH READ LOCK（主库）+ STOP SLAVE（从库）做快照级一致性校验（仅限维护窗口内）
四、长期预防比修复更重要
一次修复解决不了根本问题，需建立防护机制：
- 开启 binlog_format = ROW + enforce_gtid_consistency = ON，杜绝语句级复制的不确定性
- 从库设置 read_only = ON（并确保 super 权限用户极少使用），配合账号权限隔离
- 接入 pt-heartbeat 实时监控复制延迟，结合告警（如延迟 > 30 秒触发企业 微信 通知）
- 定期（如每周）自动运行 pt-table-checksum，异常结果自动入库并通知负责人
