能修复，但必须先确认不是延迟假象；真正不一致时，用pt-table-checksum定位+pt-table-sync修复是最稳妥路径，前提是主从表结构、字符集、权限均一致；判断真不一致需核查slave_io_running和slave_sql_running均为yes、seconds_behind_master非null且无last_sql_error报can't find record或duplicate entry。
能修复，但必须先确认不是延迟假象；真正不一致时，用 pt-table-checksum 定位 + pt-table-sync 修复是最稳妥的路径，前提是主从表结构、字符集、权限都对得上。
怎么判断是真不一致，还是只是延迟？
很多人一看到 Seconds_Behind_Master > 0 就慌着修，结果白忙活。关键看三件事：
-
Slave_IO_Running和Slave_SQL_Running必须都是Yes，否则复制链路已断，不是“不一致”，是“没在同步” -
Seconds_Behind_Master为NULL，大概率是 SQL 线程卡死（比如报错停了），不是延迟 - 真正铁证是
Last_SQL_Error出现Can't find record in 'xxx'或Duplicate entry—— 这说明数据本身对不上，不是时间差的问题
为什么必须先跑 pt-table-checksum？
它不是可选步骤，而是修复的前提。这个命令在主库执行，把每张表的校验和写进 percona.checksums 表，从库靠它知道“该信谁”。常见坑点：
- 主库账号需有
REPLICATION CLIENT和SELECT权限；从库账号至少要有SELECT - 如果输出里
DIFFS列为1，说明这张表存在行级差异；ERRORS非0要先查表结构/字符集是否严格一致 - 报
No slaves were found，通常是因为主库没设report_host，得加--recursion-method=dsn手动指定从库地址
pt-table-sync 怎么用才安全？
它不直接改数据，而是生成 SQL——所以必须先 --print，再 --execute。别跳过预览这步：
- 命令示例：
pt-table-sync --print --replicate=percona.checksums --sync-to-master h=192.168.184.152,u=dba,p=Id81Gdac_a --databases=maria -
--sync-to-master意味着所有修复操作都在主库执行（如INSERT ... ON DUPLICATE KEY UPDATE），再靠复制同步到从库，避免直写从库导致后续断裂 - 如果
DIFFS大量为1，或Last_SQL_Error反复出现Error_code: 1032（找不到记录）或1062（重复键），说明已丢失行级数据，pt-table-sync效率会急剧下降，此时该重建就重建
修复后最容易被忽略的细节
修复完别急着走。要立刻验证三件事：
- 从库执行
SHOW SLAVE STATUS\G，确认Seconds_Behind_Master = 0且无错误 - 重新跑一次
pt-table-checksum，确保所有表的DIFFS都变回0 - 检查修复涉及的表是否有触发器、外键约束——MySQL 9.6.0 把外键逻辑上移到 SQL 层，但老版本仍可能因引擎层行为差异导致修复后二次出错
