pt-table-sync 是差分应用器，依赖 pt-table-checksum 生成的 percona.checksums 表定位差异；必须存在含 DIFFS≠0 的记录，启用 --sync-to-master 保障修复安全，--print 预演必做，主从主键、字符集、权限、binlog_format 等需严格一致。
必须先有 pt-table-checksum 生成的 percona.checksums 表，pt-table-sync 才能定位差异；它不自己比对，只读校验结果——没这一步，工具直接报错退出。
校验表必须存在且含有效 DIFFS 记录
执行 pt-table-sync 前，先确认主库上 percona.checksums 表里有不一致标记：
- 运行
SELECT db,tbl,DIFFS FROM percona.checksums WHERE DIFFS != 0;，至少返回一行 - 若无结果，说明当前主从数据一致，
pt-table-sync不会做任何事 - 若表不存在或为空，
pt-table-sync报错类似No checksum records found，不是配置问题，是前置缺失 - 表名可通过
--replicate=your_db.your_table自定义，但必须与pt-table-checksum的--replicate参数完全一致
--sync-to-master 是自动化修复的安全底线
这个参数决定修复逻辑是否可控：启用后，所有 INSERT/REPLACE/DELETE 都在主库执行，靠复制机制同步到从库；不启用，就直接在从库上改，极易触发主键冲突或中断复制。
- 主库必须能识别目标从库（
SHOW SLAVE HOSTS或SHOW SLAVE STATUS可查），否则报No slaves found - 跨网络、DNS 不通、或从库未设
report_host时，改用--recursion-method=dsn+ 显式 DSN 表 - 线上环境禁止省略该参数，哪怕只是临时测试
--print 必须走完，--execute 别跳步
--print 输出的就是真实要执行的 SQL，跳过等于跳过预演。输出语句默认以主库为源、从库为目标，注意看动作类型：
-
REPLACE INTO `db`.`tbl` VALUES (...)：主从某行内容不同 -
INSERT INTO `db`.`tbl` VALUES (...)：从库缺这行 -
DELETE FROM `db`.`tbl` WHERE id = ...：从库多出脏数据 - 若
--print输出大量DELETE，尤其涉及核心表，先人工确认是否为预期（比如从库被误写入） - 执行
--execute前，建议用相同账号在主库手动START TRANSACTION后试跑几条输出语句，验证权限和逻辑
常见卡点：主键缺失、字符集不一致、权限不足
这些不是“配置错误”，而是直接导致工具终止的硬性限制：
- 从库表无主键或唯一索引 → 报错
Cannot chunk table without a primary key or unique index，加--no-check-plan强制继续（风险自担） - 主从
character_set_database不同 → CRC 校验失败，加--charset=utf8mb4统一编码 - 账号缺
SELECT、INSERT、REPLACE、DELETE、UPDATE权限 → 工具卡住或报权限拒绝，需显式授权 - 主库 binlog_format 不是
ROW→ 虽不影响pt-table-sync执行，但会导致修复无法被复制（从库收不到变更），务必检查
真正难的不是命令怎么写，而是理解 pt-table-sync 本质是个“差分应用器”：它不判断业务逻辑，只机械执行校验表里标记的“哪里少、哪里多、哪里错”。一旦校验表本身不准（比如 pt-table-checksum 运行时主从延迟突增、或被其他写入干扰），修复就会把错当对。
