pt-table-checksum必须在主库运行，通过分块计算crc32校验和并经复制同步至从库比对，是低干扰、高可靠的一致性验证方式；执行前须确保从库延迟为0、report_host/port显式配置、校验账号在各从库已授select和replication client权限。
直接在主库运行 pt-table-checksum，它自动分块计算校验值、通过复制同步到从库、再比对结果——这是最可靠、低干扰的自动对比方式，无需直连从库或手动导出比对。
必须提前确认的三项基础条件
校验结果可信的前提是环境就绪：
- 所有从库 Seconds_Behind_Master = 0，且
Slave_IO_Running和Slave_SQL_Running均为Yes - 主库显式配置
report_host和report_port（不能依赖已废弃的SHOW SLAVE HOSTS） - 校验账号（如
chkuser）已在每个从库执行授权：GRANT SELECT, REPLICATION CLIENT ON *.* TO 'chkuser'@'%'; FLUSH PRIVILEGES;
推荐的安全执行命令
避免默认行为带来的不确定性，用明确参数控制流程：
-
--recursion-method=dsn=D=percona,t=dsns：提前在主库建好percona.dsns表，填入各从库连接信息，精准控制校验范围 -
--replicate=percona.checksums：确保该表在所有从库存在、可写，结构一致 -
--no-check-binlog-format：适配ROW模式（STATEMENT模式下非必需） -
--max-lag=1：从库延迟超 1 秒自动暂停，防止校验“追着延迟跑”
示例命令：pt-table-checksum --host=192.168.10.100 --user=chkuser --password='xxx' --databases=myapp --replicate=percona.checksums --no-check-binlog-format --recursion-method=dsn=D=percona,t=dsns --max-lag=1
如何判断是否真正一致
别只看命令行输出的 DIFFS 列——它默认静默写入表，不报错也不中断：
- 执行完后，立即在主库查询：
SELECT db,tbl,chunk,master_cnt,this_cnt,master_crc,this_crc FROM percona.checksums WHERE master_cnt != this_cnt OR master_crc != this_crc; -
master_cnt = 0 && this_cnt > 0：从库有数据，主库没有（反向写入或复制过滤导致） -
this_cnt = 0 && master_cnt > 0：典型复制中断，整块数据未同步过去 - 若查询无结果，才代表当前校验范围内数据一致
常见误判与应对要点
显示一致但实际不一致？大概率是时机或配置问题：
-
Skipped 多：默认 chunk 超时 0.5 秒，大字段或慢索引易触发；可加
--chunk-time=1.0或--chunk-size=5000 -
Diffs = 0 却知道数据不对：检查
percona.checksums是否真的同步到了从库（在从库执行SELECT * FROM percona.checksums） -
Cannot chunk table because of lack of good index：表缺少单列、非空、高选择性的主键或唯一索引；临时可用
--chunk-index指定合适索引，长期建议补主键或优化索引
