pt-table-checksum必须在主库执行，通过复制将校验和同步至从库比对；不可直连从库，否则因权限、配置不匹配导致报错或卡住，且结果须查从库percona.checksums表中master_crc与this_crc是否一致。
pt-table-checksum 必须在主库执行，不能直连从库
工具设计逻辑决定了它必须运行在主库：它在主库分块计算 CRC32 校验和，生成带校验逻辑的 REPLACE INTO ... SELECT 语句，再通过 binlog 复制到从库执行——从库不是被“连接校验”，而是被动重放并本地再算一次。如果你用 --host=从库IP 强行指向从库，它会尝试在从库上干主库的事（比如改 binlog_format、查 SHOW PROCESSLIST 找 slave），但权限、配置、复制状态全不满足，大概率卡住或报错 Cannot connect to host 或 Replica mysql2 is stopped. Waiting.。
执行前必须确认的三件事：延迟、report_host、权限
缺一不可，否则结果无效或直接失败：
- 所有从库
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'@'%'
MySQL 8.0+ 还要注意认证插件兼容性：老版本 pt-table-checksum（如 3.1.x）不支持 caching_sha2_password，要么降级插件，要么升级工具。
关键参数怎么设才不踩坑
默认参数在生产环境基本不可用，必须显式控制行为：
-
--no-check-binlog-format：主库binlog_format = ROW时必须加，否则直接退出 -
--replicate=percona.checksums：确保该表在所有从库存在、结构一致、可写；首次运行建议加--create-replicate-table -
--recursion-method=dsn=D=percona,t=dsns：避免自动发现失效，在主库percona.dsns表里填死从库连接信息（host/user/pass/port） -
--max-lag=1：从库延迟超 1 秒自动暂停，防止校验“追着延迟跑” -
--chunk-time=0.5或--chunk-size=1000：大字段或慢索引易触发Skipped，调高可减少跳过，但别设太大，否则锁表时间长
示例命令：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 = 0 完全不可信——它只是告诉你“没往 percona.checksums 写差异记录”，不代表数据真一致。必须手动查表：
- 在主库执行：
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 - 在从库执行：
SELECT * FROM percona.checksums WHERE this_crc != master_crc OR is_bad = 1
常见误判点：如果从库 percona.checksums 表为空，说明复制中断或被过滤（如 replicate_ignore_db=percona）；如果只查主库没查从库，等于白跑。校验结果是否有效，永远取决于从库上那张表有没有被正确同步和更新。
