MySQL搭建主从后如何校验数据一致性_使用pt-table-sync修复差异

不能盲目执行。pt-table-sync 默认只输出 SQL 不执行，需加 --execute；须确认主库唯一写入，否则修复语句可能错误；建议先用 --dry-run + --print 验证，注意 WHERE 是否基于主键，跨版本同步需显式指定 --charset=utf8mb4。主从数据不一致时，pt-table-sync 能直接修复吗？不能盲目执行。它默认只输出 SQL 语句，不真正执行，除非显式加 --execute。很多运维在没加这个参数的情况下以为"已经修好了"，结果查了一圈发现数据还是错的。必须确认主库是唯一写入源，否则从库写入会导致 pt-table-sync 生成错误的反向修复语句建议先用 --dry-run + --print 看它打算怎么修，尤其注意 WHERE 条件是否基于主键（非主键表会退化为全表扫描比对）跨版本同步（如 MySQL 5.7 → 8.0）可能因默认字符集或隐式类型转换导致比对误判，需加 --charset=utf8mb4 显式指定校验阶段为什么 pt-table-checksum 报 Cannot chunk table because of lack of good index这是最常见的卡点：工具需要高效分块遍历表，若表没有单列、非空、有索引的整数型主键或唯一键，就会失败。临时解法是加 --chunk-index 指定一个合适的索引，但该索引必须满足"高选择性+无 NULL"------比如 created_at 时间戳索引通常不行，因为大量重复值长期方案是给大表补一个自增 id 主键，或者把联合唯一键拆成覆盖索引（如 (user_id, order_no) 上建 KEY idx_user_order (user_id, order_no)）跳过该表校验不是好主意：--ignore-table 只是掩耳盗铃，后续 pt-table-sync 也不会处理它pt-table-sync 修复后，从库延迟反而飙升了怎么办？因为它默认按主库顺序重放修复 SQL，如果差异集中在热点行（比如用户余额表里某几个 ID），所有 UPDATE 都串行打到同一个分区/页上，锁竞争剧烈。 AI智研社 AI智研社是一个专注于人工智能领域的综合性平台