应先比对gtid差异并用mysqlbinlog确认是否真实写入，再通过重设gtid_purged或重建从库修复；严禁直接修改gtid_executed，必须按stop slave→reset slave all→set global gtid_purged→change master→start slave顺序操作。
从库报“Slave has more GTIDs than master”怎么清
这是明确的 GTID 不一致信号：从库 gtid_executed 里包含了主库当前没有的 GTID，本质是“从库执行了主库没发过的事务”。不是数据超前，而是脏写或跳错残留。
别急着 RESET SLAVE ALL，先确认差异是否真实有害：
- 在从库执行
SELECT @@global.gtid_executed;，记下完整集合（如aaa-bbb-ccc-1-100,ddd-eee-fff-1-50） - 在主库执行同样命令，比出多出来的那段（比如
ddd-eee-fff-1-45-50） - 用
mysqlbinlog --base64-output=decode-rows -v查对应 binlog 文件，确认那段 GTID 是否真有INSERT/UPDATE/DELETE—— 如果是SET sql_log_bin = 0后的 DDL，可能无害；如果是从库自己写的INSERT INTO t VALUES()，就是脏数据
安全重设 gtid_purged 的前提和步骤
SET GLOBAL gtid_purged = 'xxx' 只能在 gtid_executed 为空时执行，否则报错 ERROR 1840 (HY000)。必须严格按顺序操作：
STOP SLAVE;-
RESET SLAVE ALL;（清空所有复制状态 + relay log +gtid_executed） -
SET GLOBAL gtid_purged = '主库当前的gtid_executed值';（注意：必须是主库的完整值，且不能含从库多出的部分） CHANGE MASTER TO MASTER_AUTO_POSITION = 1;START SLAVE;
如果主库 gtid_executed 是 aaa-bbb-ccc-1-100，而你误填成 aaa-bbb-ccc-1-90，从库会漏同步 91–100 这段事务，直接丢数据。
跳过单个冲突 GTID 事务的实操要点
适用于主库已发、从库执行失败（如 1032/1062 错误），但 GTID 集合本身没污染的场景。不能用 sql_slave_skip_counter，必须注入空事务：
STOP SLAVE;-
SET SESSION gtid_next = '560d72ff-b057-11ee-84ba-5254005c1b84:8';（目标 GTID） -
BEGIN; COMMIT;（必须成对，且不能在已有事务中执行，否则报ERROR 1766） SET SESSION gtid_next = 'AUTOMATIC';START SLAVE;
跳完立刻检查 SHOW SLAVE STATUS\G 中的 Exec_Master_Log_Pos 是否前进，以及 Retrieved_Gtid_Set 和 Executed_Gtid_Set 是否开始收敛。
重建从库比硬清 GTID 更可靠的情况
当从库写入不可信（比如 read_only = OFF 期间被应用直连写）、或多次跳错导致 GTID 集合混乱时，RESET SLAVE ALL + gtid_purged 可能掩盖问题。此时应放弃修复，直接重建：
- 主库导出：
mysqldump --single-transaction --set-gtid-purged=ON -u root -p db_name > full.sql - 从库清空数据库：
DROP DATABASE db_name; - 导入：
mysql -u root -p db_name - 设置
gtid_purged：导出文件开头有SET @@GLOBAL.GTID_PURGED='...';，直接执行该行 START SLAVE;
最容易被忽略的是：--set-gtid-purged=ON 必须加，否则导入后 gtid_purged 为空，从库会尝试重放全部历史 binlog，触发重复错误。这个开关决定了 dump 文件是否包含 GTID 初始化语句。
