pt-table-checksum必须在主库执行，因需通过binlog复制到从库重放以计算this_crc；直连从库会跳过复制逻辑，导致校验失效。
pt-table-checksum 必须在主库执行，且结果是否有效不看命令行输出的 Diffs = 0，而要看从库 percona.checksums 表里 this_crc != master_crc 的记录——这是绝大多数人误判一致性的根源。
为什么不能直连从库执行 pt-table-checksum
工具设计上就拒绝绕过复制链路：pt-table-checksum 在主库生成形如 REPLACE INTO percona.checksums SELECT db, tbl, chunk, CRC32(CONCAT(...)), COUNT(*) FROM ... WHERE id BETWEEN ? AND ? 的语句，这些语句必须写入 binlog，并由从库 SQL 线程重放，才能触发从库用自己的数据重新计算 this_crc。
若强行加 --host=从库IP：
- 工具会尝试在从库执行
SHOW PROCESSLIST、修改binlog_format等操作，但只读从库通常禁用SUPER权限，直接卡在Waiting for replica mysql2 - 报错常见为
Cannot connect to host或Access denied，本质是权限/配置不匹配，不是网络问题 - 即使连上，也跳过复制逻辑，变成单点校验，完全失去“主从一致性”校验意义
执行前必须确认的三件事（缺一不可）
否则工具启动即失败，或输出 0 differences 却实际漏检：
-
SHOW SLAVE STATUS\G中Slave_IO_Running = Yes、Slave_SQL_Running = Yes，且Seconds_Behind_Master接近 0（建议 ≤ 1 秒） - 主库已显式配置
report_host和report_port（SHOW SLAVE HOSTS已废弃，不能依赖） - 校验账号（如
chkuser）已在每个从库执行授权：GRANT SELECT, REPLICATION CLIENT ON *.* TO 'chkuser'@'%'；MySQL 8.0+ 还需确认认证插件兼容，老版本pt-table-checksum 3.1.x不支持caching_sha2_password
关键参数怎么设才不踩坑
默认参数在生产环境基本不可用，尤其大表场景：
-
--no-check-binlog-format：必须加，避免因binlog_format = ROW被拒绝（MySQL 5.7.7+ 默认 ROW，且pt-table-checksum实际依赖 ROW 模式下语句可重放） -
--replicate=percona.checksums：指定校验结果写入位置，必须确保该库表存在且可写；首次运行加--create-replicate-table -
--chunk-size=1000：默认按主键范围分片，1000 行/块较稳妥；过大易锁表或超时，过小则 IO 频繁、校验慢 -
--nocheck-replication-filters：必须加，否则遇到replicate_ignore_db=percona会导致从库压根不同步percona.checksums表，查出来永远空 -
--max-delay=1：从库延迟超过 1 秒就暂停，防止校验结果反映“历史状态”而非当前一致性
校验完怎么判断真一致？
命令行输出 Diffs = 0 只表示主库没写差异记录，不代表从库已同步或比对完成：
- 必须登录每台从库，手动执行：
SELECT * FROM percona.checksums WHERE this_crc != master_crc OR is_bad = 1 - 若返回空集，才说明该从库当前数据块级一致
- 若发现差异，不要直接跑
pt-table-sync：先确认是复制延迟、NULL处理差异（如CRC32(CONCAT())对 NULL 行为不一致），还是真实数据漂移 - 大表校验中若某块卡住，工具会自动跳过（因
innodb_lock_wait_timeout=1），后续可用--resume继续，但需人工检查跳过的CHUNK是否真有问题
真正容易被忽略的是：校验过程本身不验证从库的 percona.checksums 表是否完整接收并执行了所有 checksum 语句——它只管主库发没发，不管从库收没收全。所以哪怕复制链路中间断过一次，percona.checksums 表就可能缺块，而你还在信誓旦旦说“Diffs = 0”。
