pt-table-sync不校验只修复，必须先由pt-table-checksum生成percona.checksums表并确保从库已同步该表数据，否则其输出为空或误判；修复后须在从库查checksums表确认this_crc=master_crc，并手动抽样核对关键字段。
pt-table-sync 本身不校验数据一致性，它只修复——校验必须由 pt-table-checksum 完成。直接拿 pt-table-sync 去“验证”迁移结果，会得到空结果或误判。
为什么 pt-table-sync 执行后没报错，但数据还是不一致？
因为 pt-table-sync 不自己发现差异，它只读取 percona.checksums 表里的已有校验记录。如果没提前跑过 pt-table-checksum，或者主库写入的 checksum 没同步到从库（复制延迟、过滤规则、SQL线程停了），pt-table-sync 就无从得知哪几行不一致。
常见错误现象：
-
pt-table-sync --print输出为空，不是数据一致，而是 checksum 表里没差异记录 - 执行后提示
0 rows affected，但关键字段值明显不同（比如时间戳少8小时、金额为0） - 修复完再查从库
percona.checksums，仍存在this_crc != master_crc
校验前必须确认的 3 个硬性前提
缺一不可，否则 pt-table-sync 的输出毫无意义：
-
percona.checksums表必须已存在且有数据：在主库上先执行pt-table-checksum --create-replicate-table ...，确保表被创建并填充了 chunk 校验值 - 从库 SQL 线程必须运行中：
SHOW SLAVE STATUS\G中Slave_SQL_Running: Yes且Seconds_Behind_Master < 5；延迟太大时，checksum 记录还没重放完，就去查this_crc，结果必然是错的 - 从库必须能访问
percona.checksums表：默认工具用主库账号连从库，但很多生产环境从库只开SELECT权限；若报Access denied，需单独建只读账号，并用--recursion-method="dsn=t=percona.dsns"显式指定
如何安全地用 pt-table-sync 验证迁移结果
所谓“验证”，其实是通过预览修复动作来反推差异是否存在。这不是间接，而是唯一可靠方式：
- 先确保
pt-table-checksum已完成且从库已同步 checksum 记录 - 在从库所在机器执行预览命令：
pt-table-sync --print --sync-to-master h=从库IP,u=账号,p=密码 --replicate=percona.checksums --databases=目标库名 - 观察输出：只要有
REPLACE INTO或DELETE FROM语句，就说明存在不一致；若完全无输出，才可初步判断该库下所有表一致 - 注意字段级陷阱：预览语句里若出现
NULL替换、''转NULL、datetime被截断为date，说明源目标库存在隐式类型转换，得回溯迁移过程中的字符集/时区/精度配置
修复后怎么才算真正“验完”了？
执行 --execute 只是把差异修掉，不代表问题根除。必须做两件事：
- 修复完成后，立刻在从库执行：
SELECT * FROM percona.checksums WHERE this_crc != master_crc OR is_bad = 1;—— 这才是最终一致性判决书 - 挑 3–5 张关键业务表（如订单、用户、资金流水），手动比对几条边界数据：主库
SELECT * FROM t WHERE id IN (x,y,z)，从库执行相同语句，逐字段肉眼核对，尤其注意TIMESTAMP、DECIMAL、TEXT类型
不要相信“0 differences found”这种日志摘要，也不要跳过手动抽样——迁移后最危险的不一致，往往藏在类型转换和空值处理里，工具算出来的哈希值一致，不代表业务可接受。
