GTID要求事务与GTID严格一一对应，CREATE TABLE ... SELECT在MySQL 8.0.21前因DDL/DML拆分导致GTID不一致而报错；8.0.21+通过原子DDL日志实现单事务建表与插入，满足GTID一致性要求。
GTID要求事务与GTID严格一一对应
GTID的核心机制是“一个事务 → 一个GTID”，复制链路上依赖这个一对一关系做幂等校验和位点追踪。一旦某个语句在内部拆成多个逻辑事务（比如 CREATE TABLE ... SELECT 实际执行 CREATE TABLE + INSERT INTO ... SELECT），但对外只暴露一个语句边界，MySQL 就无法安全分配唯一 GTID —— 因为 DDL 自动提交、DML 可能跨事务，二者可能被分配不同 GTID，破坏一致性。
- 典型表现：执行
CREATE TABLE t2 AS SELECT * FROM t1;报错ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TABLE ... SELECT - 根本原因不是语法本身，而是该语句在 binlog 中的行为不可控：STATEMENT 格式记为 1 个 GTID，ROW 格式记为 2 个 GTID；主从格式不一致时直接导致复制中断
- 同样逻辑也适用于混合引擎操作，例如
UPDATE t_innodb, t_myisam SET ...：InnoDB 部分可回滚，MyISAM 不可，事务原子性失效，GTID 无法锚定完整效果
MySQL 8.0.21+ 解除了 CREATE TABLE ... SELECT 限制
这个限制的解除不是“绕过”，而是靠底层能力升级：MySQL 8.0 引入原子 DDL 日志（mysql.ibd + ddl_log），让建表和写入数据能在单个原子事务中完成，从而满足 GTID 对“一个事务一个 GTID”的硬性要求。
- 前提条件：必须是支持原子 DDL 的存储引擎（InnoDB 是默认且主要支持者；MyISAM 不支持，仍会报错）
- 验证方式：运行
SELECT VERSION();确认 ≥ 8.0.21，且SHOW VARIABLES LIKE 'enforce_gtid_consistency';返回ON仍可成功执行 - 注意：即使版本达标，若表含 FULLTEXT 或 SPATIAL 索引，或目标表名已存在（非
IF NOT EXISTS），仍可能失败 —— 这些属于原子 DDL 的例外场景，不是 GTID 问题
CREATE TEMPORARY TABLE 在 GTID 下的行为分阶段
临时表是否允许，取决于 MySQL 版本、binlog_format 和上下文，不是简单“禁用”或“启用”。
- MySQL 5.7 及更早：在存储过程、函数、触发器或显式事务内禁止
CREATE TEMPORARY TABLE；仅当autocommit = 1且不在任何事务块中才允许 - MySQL 8.0.13+：当
binlog_format = ROW或MIXED时，允许在事务/过程/函数中使用；因为临时表不写入 binlog，从库无需同步，不会破坏 GTID 事务流 - 关键细节：如果事务中只有
DROP TEMPORARY TABLE且无其他变更，该事务会被优化为空事务，不写入 binlog —— 所以你用SHOW BINLOG EVENTS可能根本看不到它
真正容易被忽略的陷阱是隐式引擎切换
你以为自己只用了 InnoDB，但触发器、视图、或者未显式指定 ENGINE 的 CREATE TABLE，可能悄悄引入 MyISAM 表（尤其在老配置或迁移库中）。这类问题不会立刻报错，而是在某次跨库复制时突然中断，错误日志里只显示模糊的 GTID mismatch。
- 排查方法：检查所有涉及表的引擎：
SELECT TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'your_db'; - 特别关注触发器定义：
SELECT TRIGGER_NAME, ACTION_STATEMENT FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_OBJECT_SCHEMA = 'your_db';—— 若其中含INSERT INTO myisam_table，就踩雷了 - 修复建议：统一显式声明
ENGINE=InnoDB，禁用 MyISAM（skip-innodb = OFF不等于 MyISAM 不可用；需设disabled_storage_engines = "MyISAM"）
