pt-table-sync必须依赖pt-table-checksum生成的percona.checksums表才能定位差异，否则报错退出；启用--sync-to-master确保修复在主库执行并经复制同步到从库，--print必须先运行以预览INSERT/REPLACE/DELETE语句，避免误操作。
pt-table-sync 能直接修复主从数据差异，但必须先有 pt-table-checksum 的校验结果，否则它连“哪里不一致”都不知道。
必须先跑完 pt-table-checksum 才能用 pt-table-sync
pt-table-sync 不自己比对数据，它只读 percona.checksums 表里的差异记录。如果没提前执行过 pt-table-checksum，或者校验表为空/不存在，工具会报错退出，不会尝试盲同步。
- 主库上执行校验（需确保 binlog_format=ROW，且从库在
SHOW SLAVE HOSTS中可见）：pt-table-checksum --replicate=percona.checksums --no-check-binlog-format h=192.168.184.150,u=dba,p=Id81Gdac_a - 校验完成后，检查
percona.checksums表中DIFFS列是否为 1：SELECT db,tbl,DIFFS FROM percona.checksums WHERE DIFFS != 0; - 若无结果，说明当前主从数据一致，
pt-table-sync无事可做
--sync-to-master 是安全模式的关键开关
这个参数决定修复逻辑的走向：启用后，所有修复语句都在主库执行，靠复制机制同步到从库；不启用，则直接在从库上 DELETE/REPLACE，极易引发复制中断或主键冲突。
- 推荐始终加
--sync-to-master，尤其在线上环境 - 它要求目标从库必须能被主库识别（即
SHOW SLAVE STATUS或SHOW SLAVE HOSTS可查），否则会报No slaves found - 若从库不可见（比如跨网络、report_host 未设），改用
--recursion-method=dsn+ 显式指定从库 DSN
--print 必须先跑，--execute 别手抖
输出的 SQL 就是真实要执行的操作，跳过这步等于闭眼动手术。
-
--print输出的是在主库上执行的语句（如REPLACE INTO `maria`.`t1` VALUES (...)），不是从库上的 - 注意看语句类型：对缺失行是
INSERT，对多出行是DELETE，对内容不同是REPLACE - 如果输出里出现大量
DELETE，尤其是涉及核心业务表，务必确认这是预期行为（比如从库误写入脏数据） - 执行
--execute前，建议用相同账号手动在主库上START TRANSACTION后试跑几条，验证权限和逻辑
常见失败原因和绕过方式
工具卡住或报错，八成出在这几个点：
- 从库表缺少主键或唯一索引：报错
Cannot chunk table without a primary key or unique index，pt-table-sync默认拒绝操作——加--no-check-plan强制继续（风险自担） - 字符集不一致：主从
character_set_database不同会导致 CRC 校验失败，加--charset=utf8mb4统一显式指定 - 权限不足：从库需
SELECT，主库需SELECT, INSERT, UPDATE, DELETE, REPLICATION CLIENT；缺REPLICATION CLIENT会无法获取 binlog 位置，影响 chunk 切分 - 大表卡住：默认按主键分块，若主键稀疏或无序，可能单 chunk 耗时极长；可加
--chunk-size=1000人工控制粒度
真正容易被忽略的是：修复过程本身会产生新的 binlog，如果从库延迟高或复制线程脆弱，可能雪上加霜。别只盯着“数据修好了”，得盯住 Seconds_Behind_Master 是否在缓慢回落——否则修完立刻又裂开。
