主从校验前须先确认无复制延迟且服务正常，再用pt-table-checksum行级校验（主库运行、row/mixed模式），结果存入指定表；不一致时用pt-table-sync配合--print预览修复语句，注意连接目标与冲突策略。
主从校验前先确认是否真存在不一致
很多“读取不一致”其实是应用没走对从库，或者事务还没提交就被读了。先别急着跑校验工具，用 SHOW SLAVE STATUS\G 看 Seconds_Behind_Master 是否为 0，再查 Slave_SQL_Running 和 Slave_IO_Running 都是 Yes。如果延迟非零，那不是数据不一致，是复制滞后——这时候强制校验没意义，得先定位延迟原因（比如大事务、从库磁盘慢、网络抖动）。
用 pt-table-checksum 做行级一致性校验
这是 Percona Toolkit 里最靠谱的主从数据比对工具，它在主库上分块计算 checksum，通过复制机制把校验语句传到从库执行，再回传结果对比。关键点在于：
- 必须在主库上运行，且主库 binlog_format 要设为
ROW或MIXED（STATEMENT模式下某些函数会导致从库 checksum 计算结果不同） - 默认只校验
utf8mb4字符集表，如果库中有latin1或gbk表，得加--charset=utf8mb4显式指定，否则跳过或报错 - 大表建议加
--chunk-size=10000控制分块大小，避免锁表太久；加--replicate=test.checksums把结果存到指定库表，方便后续用pt-table-sync修复 - 常见错误：
Cannot chunk table `db`.`t1`: Cannot get a consistent MySQL connection，一般是主从账号权限不足，需确保账号有SELECT、PROCESS、SUPER（或REPLICATION CLIENT）权限
发现不一致后怎么安全修复
pt-table-sync 是配套修复工具，但它默认只输出 SQL，不自动执行。强烈建议先用 --print 看它打算怎么修，再人工评估：
- 修复语句默认走从库连接，但如果从库有写入（比如双写场景），可能覆盖业务数据——此时要用
--sync-to-master让它连主库生成修复语句，再手动在从库执行 - 遇到唯一键冲突时，
pt-table-sync默认用REPLACE INTO，但有些场景需要保留从库最新值（比如从库有本地更新），就得加--no-replace改用INSERT ... ON DUPLICATE KEY UPDATE - 修复前务必确认从库没有正在运行的长事务，否则
pt-table-sync可能被阻塞，甚至触发死锁
MySQL 8.0+ 的 CHECKSUM TABLE 不适合主从校验
有人想用 CHECKSUM TABLE t1 在主从分别执行然后比对结果，这不可靠。因为：
-
CHECKSUM TABLE对TEXT/BLOB字段的处理受sql_mode和字符集排序规则影响，主从稍有差异就导致 checksum 不同 - 它不区分行顺序，而主从复制中相同数据的插入顺序可能因并行复制线程调度不同而变化，checksum 却会变
- 它无法检测缺失行或多余行，只能反映“当前存在的行内容总和”，漏掉单行增删都发现不了
所以别图省事，老实用 pt-table-checksum。它的分块 + 复制流校验机制才是为生产环境设计的。
真正麻烦的从来不是工具怎么跑，而是校验过程中主库流量突增、从库负载飙升、或者修复时误删了本该保留的本地变更——这些细节不会报错，但会悄悄埋雷。
