MySQL主从复制不同步应优先定位差异、停写入、安全修复：先查SHOW SLAVE STATUS中的Seconds_Behind_Master、IO/SQL线程状态及Last_SQL_Error；再用pt-table-checksum/sync精准修复；差异过大时重建从库。

MySQL主从复制不同步，核心是定位差异点、停止写入干扰、安全修复数据，而不是直接跳过错误或重做从库——后者成本高、风险大。

快速判断不同步程度和原因

先登录从库执行：
SHOW SLAVE STATUS\G
重点关注三项：

• Seconds_Behind_Master：大于0说明有延迟，但为NULL或0不一定代表完全一致（可能IO/SQL线程已停止）
• Slave_IO_Running 和 Slave_SQL_Running：必须都是Yes，任一为No即复制中断
• Last_SQL_Error：直接暴露SQL执行失败原因（如主键冲突、表不存在、语句被过滤等）

再比对主从的Exec_Master_Log_Pos与Read_Master_Log_Pos，若差距持续扩大，说明IO线程拉日志正常但SQL线程处理不过来（常见于大事务、从库性能差、慢查询未优化）。

轻量级修复：跳过单条错误（仅限明确可丢弃的操作）

适用于DDL已存在、重复插入主键冲突等“无业务影响”的场景。操作前务必确认主库该事件确实不该在从库执行：

• 停止复制：STOP SLAVE;
• 跳过一条事件：SET GLOBAL sql_slave_skip_counter = 1;
• 启动复制：START SLAVE;

⚠️ 注意：该方式不推荐用于GTID模式；GTID下应使用SET GTID_NEXT + 空事务方式跳过，否则会破坏GTID一致性。

精准修复：用pt-table-checksum + pt-table-sync校验并修复

Percona Toolkit是生产环境最稳妥的数据一致性修复组合：

• 在主库上运行pt-table-checksum，生成校验和并同步到从库
• 从库执行pt-table-sync --replicate=... --sync-to-master，自动比对并生成修复SQL（建议先加--print预览）
• 修复时加--execute执行，全程不锁表，支持分批、限速、指定库表

优势在于只修差异行，不影响正常业务；缺点是需安装Perl依赖，且主从表结构、字符集必须严格一致。

终极方案：重建从库（当差异过大或修复失败时）

不是重装MySQL，而是重新构建一个干净的从库：

• 主库执行FLUSH TABLES WITH READ LOCK;，记下SHOW MASTER STATUS的文件名和位置
• 用mysqldump --single-transaction --master-data=2导出（确保一致性快照）
• 从库导入后，用记录的binlog位置执行CHANGE MASTER TO ... MASTER_LOG_FILE='...', MASTER_LOG_POS=...
• 启动复制：START SLAVE;

整个过程主库只读锁时间极短（几秒），适合中大型系统。关键点是--master-data=2会把CHANGE语句写进dump文件，避免手动定位位置出错。

不复杂但容易忽略：修复后务必持续观察Seconds_Behind_Master是否稳定归零，并抽查几个核心表的COUNT和SUM结果是否一致。