pt-table-checksum必须在主从复制链路中以主库为起点运行，依赖binlog将校验语句复制到从库执行并比对CRC32值；迁移目标库无复制链路、未启用log_slave_updates、通常只读，直接运行会因“No slaves found”失败或结果不可信。
pt-table-checksum 不是为“迁移后一次性校验”设计的，直接在迁移目标库上运行会失败或结果不可信；它必须在主从复制链路中、以主库为起点、依赖 binlog 复制机制同步校验行为——迁移场景需先构建临时主从关系，再按复制一致性流程走。
为什么不能直接在校验迁移目标库时用 pt-table-checksum
迁移（如 mysqldump + load、Percona XtraBackup 恢复、DMS 同步）完成后，目标库是独立实例，没有 binlog 复制链路：pt-table-checksum 的核心逻辑是：在主库执行 REPLACE INTO percona.checksums，靠复制把这条语句“重放”到从库，让从库自己算一遍对应 chunk 的 CRC32 值并写入本地 percona.checksums 表。若目标库没接主库的 binlog，这个过程就断了——工具会报 No slaves found 或写入后从库表为空，根本比不出差异。
- 迁移目标库通常关闭
log_slave_updates，且没配置relay_log，不具备“作为从库参与校验”的基础能力 - 即使强行指定
--recursion-method=dsn并填入目标库地址，工具仍会尝试在目标库上执行写操作（如建表、INSERT），而多数迁移目标库只开放只读账号或禁止写percona库 - 迁移过程本身可能已引入不一致（如字符集转换、timestamp 精度截断、自增 ID 冲突），
pt-table-checksum无法回溯这些源头问题，只能比“当前快照”
迁移后校验的正确做法：临时搭主从，再跑 pt-table-checksum
本质是把迁移源库设为临时主库，目标库设为临时从库，建立单次、短生命周期的复制通道，让 pt-table-checksum 的机制能跑通。关键步骤如下：
- 在目标库执行
CHANGE MASTER TO，指向源库 IP/端口/账号，并开启log_slave_updates = ON（否则 checksum 记录无法落盘） - 启动复制：
START SLAVE;，确认Slave_IO_Running: Yes且Seconds_Behind_Master快速归零（说明全量数据已追平） - 在源库（即临时主库）上运行
pt-table-checksum，必须加--no-check-binlog-format（因迁移后 binlog 格式常为 ROW，而工具默认只适配 STATEMENT）和--no-check-replication-filters（避免因迁移时遗留的replicate-ignore-db规则跳过校验） - 等待校验完成（可通过
SELECT * FROM percona.checksums WHERE db='xxx' ORDER BY ts DESC LIMIT 5;查主库写入时间），再立刻查目标库：SELECT db, tbl, this_crc, master_crc FROM percona.checksums WHERE this_crc != master_crc;
pt-table-checksum 在迁移场景下的参数雷区
迁移环境与常态主从不同，几个参数稍不注意就会导致校验跳过、超时或误报：
-
--chunk-time=0.1：迁移后目标库性能常不稳定，把默认 0.5 秒压到 0.1 秒，避免 chunk 执行超时被跳过 -
--max-lag=5：迁移刚结束时复制延迟可能抖动，放宽阈值防工具反复暂停；但别设太高，否则延迟掩盖真实不一致 -
--replicate=percona.checksums必须显式指定，且确保源库和目标库的percona库都存在、可写；若目标库无percona库，需提前手动创建 - 绝对不要用
--replicate-check-only：该模式要求工具直连从库查表，但迁移目标库往往网络策略严格，连通性难保障，优先走复制同步路径
校验结果怎么看才不被误导
迁移后 percona.checksums 表里出现 master_crc != this_crc，不等于数据一定错——得先排除迁移过程引入的“合法差异”：
- 检查
this_cnt != master_cnt：若仅计数差 1 行但this_crc == master_crc，大概率是迁移时某条记录的datetime字段因时区或精度被调整（如NOW()变成固定值），CRC 仍一致 - 抽样对比具体行：
SELECT * FROM <table> WHERE id BETWEEN <lower_boundary> AND <upper_boundary> 分别在源库和目标库执行，用 <code>diff工具比文本输出，确认是字段值差异还是空格/换行符等无关紧要区别 - 忽略
information_schema和mysql系统库：迁移通常不导这些库，pt-table-checksum若扫到会报错或填空值，加--ignore-databases=information_schema,mysql
真正麻烦的是 CRC 和计数同时不一致——这基本锁定为迁移过程中发生了隐式类型转换、字符集截断或 SQL_MODE 不兼容（比如源库 STRICT_TRANS_TABLES 关闭，目标库开启，导致某条 INSERT 被静默拒绝）。这种差异没法靠 pt-table-sync 自动修复，得人工重放迁移语句并加 SHOW WARNINGS 定位。
