ERROR 3546的根本原因是备份文件中的SET @@GLOBAL.GTID_PURGED语句试图强行覆盖目标库非空的gtid_executed，而两者GTID集合存在重叠，MySQL为防事务重复或跳变主动拒绝该操作。
根本原因不是GTID本身，而是备份文件里那行 SET @@GLOBAL.GTID_PURGED=... 在导入时强行覆盖目标库当前的 gtid_executed 状态，而两者存在重叠。
为什么 SET @@GLOBAL.GTID_PURGED 会触发 ERROR 3546
MySQL 在执行该语句时会做严格校验：新设置的 gtid_purged 集合不能与当前已执行的 gtid_executed 有任何交集。一旦重叠（比如备份声明 “已执行 1-100”，而目标库实际已执行 1-105），就会报错：
ERROR 3546 (HY000): @@GLOBAL.GTID_PURGED cannot be changed: the added GTID set must not overlap with @@GLOBAL.GTID_EXECUTED
这不是“不允许导入”，而是 MySQL 主动拒绝一个可能导致事务重复或跳变的操作。
- 重叠 ≠ 数据重复，但意味着 MySQL 无法安全判断哪些事务该跳过、哪些该执行
- 哪怕目标库是空的，只要它之前启动过、执行过任何语句（包括
CREATE DATABASE），gtid_executed就可能非空 -
mysqldump --master-data=2默认启用--set-gtid-purged=ON，你没显式关，它就自动写这行
为什么 --set-gtid-purged=OFF 不等于“关闭 GTID”
这个参数只控制备份文件是否包含 SET @@GLOBAL.GTID_PURGED=... 和 SET @@SESSION.SQL_LOG_BIN=0 这类元信息，和目标实例本身的 gtid_mode 无关。
- 目标库仍是 GTID 模式，只是导入时不强求对齐历史 GTID 范围
- 导入过程中的每条语句仍会生成新的 GTID，并自然追加到
gtid_executed中 - 相比
RESET MASTER，它不破坏 binlog 文件、不清空gtid_executed、不中断复制链路 - 注意：旧版
mysqldump（如 5.7.20 之前）在--set-gtid-purged=OFF下仍可能漏写SQL_LOG_BIN=0，导致主从丢失变更；建议升级或手动检查
如何验证备份文件是否“干净”
导入前快速确认它不会带 GTID 声明：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
head -20 backup.sql | grep -i "gtid\|SQL_LOG_BIN"
理想输出应为空。如果看到：
-
SET @@GLOBAL.GTID_PURGED=...→ 必须删或注释掉整行 -
SET @@SESSION.SQL_LOG_BIN = 0;→ 若目标库是主库或参与复制，这行会导致后续变更不记 binlog，必须删 -
-- GTID state at the beginning of the backup→ 注释块，可留可删，不影响执行
真正危险的是那两行 SET 语句，不是注释。
最容易被忽略的一点
即使你用了 --set-gtid-purged=OFF 或手动删了 GTID 声明，导入后 Executed_Gtid_Set 也**不会**和原主库完全一致——GTID 同步靠的是后续 binlog 流持续追平，不是靠备份那一刻的快照。恢复后务必检查 SHOW SLAVE STATUS\G 中的 Executed_Gtid_Set 是否最终收敛，而不是只看导入是否成功。
