mysql主从不一致主要由复制延迟或永久性偏差导致，可通过seconds_behind_master、日志位置比对及时间戳测试判断；须设binlog_format=row、禁用临时表与set sql_log_bin=0；推荐pt-table-checksum校验并配合pt-table-sync修复。
主从复制延迟导致的数据不一致怎么发现
MySQL 主从不一致最常见表现是 SELECT 在从库查不到刚在主库插入的记录，或查到旧值。这不是“数据丢了”，而是复制有延迟（Seconds_Behind_Master > 0）。真正危险的是延迟掩盖了逻辑错误——比如主库执行了误删，从库还没同步，此时你去从库备份，就备份了一份“已损坏但尚未传播”的状态。
判断是否真延迟而非永久不一致，优先看：
- SHOW SLAVE STATUS\G 中的 Seconds_Behind_Master（注意：该值在 IO 线程卡住时可能为 0，但实际已落后）
- 对比主从的 Exec_Master_Log_Pos 和 Read_Master_Log_Pos，若两者不等，说明 SQL 线程没追上 IO 线程
- 在主库写入带时间戳的测试行，立刻在从库查，确认是否及时可见
如何避免因 binlog 格式引发的一致性风险
binlog_format 直接决定从库重放语句的可靠性。用 STATEMENT 模式时，像 NOW()、UUID()、INSERT ... SELECT 带不确定排序的语句，在从库执行结果可能和主库不同；ROW 模式记录每一行变更，安全性高，但日志体积大、对大事务压力明显。
生产环境必须设为：
- binlog_format = ROW（5.7+ 默认，但老实例常仍为 STATEMENT）
- 同时开启 binlog_row_image = FULL（避免部分更新字段丢失上下文）
- 禁用 CREATE TEMPORARY TABLE 类操作（临时表不写 binlog，从库缺失依赖）
- 避免在从库执行 SET sql_log_bin = 0 后的写入（这类写入不会同步回主库，且可能污染从库状态）
主从校验工具选型与使用要点
人工比对不现实，得靠工具。核心诉求是：不锁表、低开销、能定位到具体行。
【极品模板】出品的一款功能强大、安全性高、调用简单、扩展灵活的响应式多语言企业网站管理系统。 产品主要功能如下： 01、支持多语言扩展（独立内容表，可一键复制中文版数据） 02、支持一键修改后台路径； 03、杜绝常见弱口令，内置多种参数过滤、有效防范常见XSS； 04、支持文件分片上传功能，实现大文件轻松上传； 05、支持一键获取微信公众号文章（保存文章的图片到本地服务器）； 06、支持一键
推荐方案：
- pt-table-checksum（Percona Toolkit）：主流选择，基于 chunk 分片校验，主库生成 checksum，从库执行对应查询并比对
- 必须在主库运行，且所有从库的 report_host 配置正确，否则无法自动发现从库
- 运行前确保从库 read_only = ON，否则校验期间写入会导致误报
- 首次运行建议加 --no-check-binlog-format 跳过格式检查（避免因格式非 ROW 报错中断），但前提是已确认 binlog 是 ROW
- 若发现差异，用 pt-table-sync 修复，但务必先在测试环境验证修复逻辑
哪些操作会绕过复制造成永久不一致
有些写操作天生不走 binlog，或者被显式跳过，一旦发生，从库永远缺失这部分数据。
典型场景包括：
- 主库执行 INSERT INTO t VALUES (1, 'a') /* mysql replica skip */（带注释跳过）
- 使用 replicate_ignore_db 或 replicate_wild_ignore_table 配置，但规则匹配过于宽泛，误过滤关键库表
- 从库开启 skip_slave_start，重启后复制未自动启动，期间主库写入全部丢失
- 主库用 LOAD DATA INFILE 且未启用 binlog_load_from_remote_server，导致从库无法加载相同文件
- 手动修改从库数据（如修复脏数据），又未同步改写主库，形成单向偏差
一致性不是“设好就完事”的状态，而是一组持续生效的约束组合：正确的 binlog 格式、受控的写入路径、定期校验机制，以及对任何手动干预的严格审计。最容易被忽略的，是那些“只在从库临时执行一下”的 SQL——它们往往没有日志、没有备份、也没有人记得。
