pt-table-checksum在主库运行，自动分块计算校验值并复制到从库比对，是低干扰一致性验证标准方式；执行前须确保从库延迟为0、report_host/port显式配置、校验账号在各从库已授权SELECT和REPLICATION CLIENT。
直接在主库上运行 pt-table-checksum，它会自动分块计算每张表的校验值，并通过复制机制同步到从库，再比对主从双方的 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在从库执行） -
MySQL 8.0+ 连不上：确认校验用户认证插件为
mysql_native_password，或升级 pt-toolkit 至 3.5+ -
GTID 环境下漏检：必须用
--recursion-method=dsn，禁用基于 processlist 的自动发现
