MySQL 8.0主从数据一致需主动验证：先确认Replica_IO_Running、Replica_SQL_Running为Yes且Seconds_Behind_Master持续为0、日志位置稳定递增；再用pt-table-checksum配合ROW格式、log_slave_updates=ON等参数校验，并手动查从库percona.checksums表比对CRC与行数；小表可用CHECKSUM TABLE快速交叉验证。
新搭建的 MySQL 8.0 主从复制，光看 SHOW REPLICA STATUS\G 里两个 Running 是 Yes 并不等于数据一致——它只说明线程在跑，不保证每条记录都对得上。必须主动验证，否则上线后才发现主从差几万行，就晚了。
先确认复制状态是否真稳定
很多人跳过这步直接校验，结果白忙活。从库必须满足三个条件才算“可校验”：
-
Replica_IO_Running和Replica_SQL_Running都是Yes -
Seconds_Behind_Master持续为0（不是偶尔跳一下） -
Read_Master_Log_Pos和Exec_Master_Log_Pos在持续递增，且差值稳定（说明 SQL 线程没卡住）
如果 Seconds_Behind_Master 一直 > 0，先查慢查询、大事务或从库磁盘 I/O；别急着跑 pt-table-checksum，它只会把延迟放大。
用 pt-table-checksum 校验前必须配对的参数
pt-table-checksum 不是“一跑就准”，MySQL 8.0 下最容易翻车的是 binlog 格式和权限配置：
- 主库
binlog_format必须是ROW（STATEMENT模式下NOW()、UUID()等函数会导致从库 checksum 不一致） - 从库必须开启
log_slave_updates=ON（否则percona.checksums表无法同步到从库） - 执行工具的账号，在从库上至少要有
SELECT权限（查percona.checksums），不能只给主库权限 - 避免用
--nocheck-replication-filters直接跳过检查——如果主库配置了replicate_ignore_db，而percona库恰好被忽略，checksum 就根本不会同步过去
推荐命令加这两个关键参数：--replicate=percona.checksums --databases=your_db_name，缩小范围，也减少误伤。
校验后必须手动查从库的 checksum 表
pt-table-checksum 执行完输出 “0 differences found” ≠ 数据一致。它只是说“主库算完了”，并不自动连从库比对：
- 必须登录从库，执行：
SELECT * FROM percona.checksums WHERE this_crc != master_crc OR is_bad = 1; - 如果返回空结果，才表示该库下所有表 CRC 一致
- 若某张表
this_cnt != master_cnt，说明行数已不一致，CRC 失效，得人工查原因（比如从库被误删过数据） - 注意
is_bad = 1字段：它代表校验过程出错（如锁超时、连接中断），不是数据差异，但同样要处理
别信工具最后一行输出——它只反映主库端执行是否报错，不反映从库真实状态。
小表可用 checksum table 快速交叉验证
对单张小表（比如 config、status 这类几十行的配置表），不用上 pt-table-checksum 也能快速验证：
- 主库执行：
CHECKSUM TABLE your_table;，记下Checksum值 - 从库执行同样命令，对比数值是否完全一致（注意：大小写敏感，且
CHECKSUM TABLE在 MySQL 8.0 中默认使用INNODB引擎的物理页校验，比CRC32(CONCAT(...))更可靠） - 如果值不同，立刻停掉业务写入，查
SHOW REPLICA STATUS\G的Last_SQL_Error字段——大概率是某个 DML 被从库跳过了
这个方法快、轻量、无侵入，适合上线前 5 分钟做最终确认。但仅限小表，大表会锁表且耗时不可控。
