MySQL主从复制不同步，核心是定位差异点、停止写入干扰、安全修复数据，而不是直接跳过错误或重做从库——后者成本高、风险大。
快速判断不同步程度和原因
先登录从库执行：
SHOW SLAVE STATUS\G
重点关注三项：
再比对主从的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结果是否一致。
