CREATE TABLE ... AS SELECT 被拒绝，因其在GTID模式下本质是DDL+DML两个独立操作，需两个GTID但仅被分配一个，破坏“一事务一GTID”原子性；MySQL 5.7直接报错1786，8.0+借助DDL原子性才支持。
开启 GTID 后，MySQL 强制要求「一个事务 = 一个 GTID」，而某些 SQL 语句天然会拆成多个逻辑单元（比如 DDL + DML），或跨引擎混用事务状态，这就直接违反了 GTID 的原子性前提——不是 MySQL 故意设障，是机制本身无法给“半个事务”分配 GTID。
为什么 CREATE TABLE ... AS SELECT 会被拒绝
这条语句在 binlog 中实际被记录为两个独立 event：一个是 CREATE TABLE（DDL，自动提交），另一个是 INSERT ... SELECT（DML）。GTID 模式下，整个语句只能分配一个 GTID，但两个 event 却需要各自拥有唯一 GTID 才能被从库正确识别和去重。否则从库可能跳过第二个 event，导致表结构存在、数据为空。
- MySQL 5.7 直接报错：
ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TABLE - 即使你把
binlog_format设为ROW，也无法绕过——因为语义上它仍是两个操作，GTID 层面仍不满足“一一对应” - MySQL 8.0+ 借助 DDL 原子性才真正支持该语句，5.7 及更早版本必须拆成两步：
CREATE TABLE ... LIKE+INSERT INTO ... SELECT
为什么不能在同一个事务里混用 InnoDB 和 MyISAM 表
InnoDB 支持事务，MyISAM 不支持；当一条 UPDATE t1, t2 同时操作两种引擎时，InnoDB 部分走事务流程，MyISAM 部分立刻落盘——MySQL 无法用单个 GTID 描述这种“部分提交、部分不回滚”的状态。
- 报错典型提示：
ERROR 1785 (HY000): When @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1 - 即使手动
SET autocommit=0开启事务，MyISAM 的修改仍会立即生效，破坏 GTID 要求的“全成功或全失败”语义 - 临时解法是把 MyISAM 表转成 InnoDB（
ALTER TABLE t2 ENGINE=InnoDB），否则只能拆事务、分步执行
为什么 CREATE TEMPORARY TABLE 必须在 autocommit=1 下单独执行
临时表生命周期绑定会话，且不写 binlog（除非显式 log_bin_trust_function_creators=ON 并配合特殊配置）；而 GTID 要求所有写操作都可追溯、可重放。如果把它塞进事务，SQL 线程回放时无法保证临时表上下文一致。
- 在事务内执行会报：
ERROR 1785或ERROR 1435（取决于具体版本） - 必须确保：
autocommit=1，且不在任何BEGIN/START TRANSACTION块中 - 注意：
DROP TEMPORARY TABLE同样受此约束，不能放在事务末尾“配套清理”
这些限制不是配置疏漏或权限问题，而是 GTID 模式下事务边界的刚性定义所致。最容易被忽略的一点是：哪怕你只在从库上执行这类语句（不涉及复制），只要 enforce_gtid_consistency=ON 生效，MySQL 就会拦截——因为它要确保“任何可能进入 binlog 的语句”都符合 GTID 规则，以防未来某天开启主从时突然出错。
