因为临时表语句在 gtid 模式下默认被当作“破坏事务原子性”的操作拦截。mysql 要求每个事务严格对应一个 gtid，而 create temporary table 在老版本中不被记录到二进制日志的事务上下文中，导致 gtid 不一致。
为什么存储过程里不能用 CREATE TEMPORARY TABLE
因为临时表语句在 GTID 模式下默认被当作“破坏事务原子性”的操作拦截。MySQL 要求每个事务严格对应一个 GTID，而 CREATE TEMPORARY TABLE 在老版本（
实际表现是执行 BEGIN; CREATE TEMPORARY TABLE tmp (id INT); COMMIT; 直接报错：ERROR 1787 (HY000): Statement violates GTID consistency: CREATE TEMPORARY TABLE...
- MySQL 8.0.13+ 允许在事务/存储过程中使用，前提是
binlog_format必须为ROW或MIXED（STATEMENT格式仍禁止） - 临时表本身不复制，所以从库无需同步；但 MySQL 需靠 binlog 格式确认该语句是否安全跳过
- 即使允许，也仅限于当前连接可见的临时表，不影响 GTID 分配逻辑
CREATE TABLE ... SELECT 在存储过程里仍受限？
不是语法本身被禁，而是它在底层触发两次事务边界：一次 DDL（建表），一次 DML（插入）。GTID 要求单语句 → 单 GTID，但这个语句在 binlog 中可能被拆成两个事件（尤其 ROW 格式），导致主从 GTID 数量不一致。
错误信息典型为：ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TABLE SELECT
- MySQL 8.0.21+ 解除了该限制，但仅限支持原子 DDL 的引擎（如 InnoDB）；MyISAM 表仍会失败
- 即使版本达标，若目标表已存在（没加
IF NOT EXISTS）、含 FULLTEXT 索引、或跨库引用非事务表，仍会触发报错 - 存储过程里调用该语句，和交互式执行受同样校验——
enforce_gtid_consistency = ON时一律拦截
混合引擎操作在存储过程中更危险
存储过程容易隐式引入多引擎操作：比如触发器里更新 MyISAM 表、视图底层查了 MyISAM、或没显式指定 ENGINE=InnoDB 导致建表落到默认引擎（老配置下可能是 MyISAM）。这类操作在 GTID 下直接破坏“事务 ↔ GTID”一对一映射。
典型报错：ERROR 1785 (HY000): Updates to non-transactional tables can only be done in either autocommitted statements or single-statement transactions...
- 哪怕只是
UPDATE t_innodb JOIN t_myisam ON ...这种单条 SQL，在存储过程里也会被拒绝 - 错误发生在解析阶段，不等真正执行——MySQL 提前扫描语句涉及的表引擎并做校验
- 最隐蔽的坑是：你没写 MyISAM，但某个被调用的函数/触发器/视图依赖了它
绕过限制的真实可行路径
别硬改 GTID 设置（enforce_gtid_consistency = OFF 是高危操作），而是按语义拆解动作，让每一步都满足 GTID 原子性要求。
- 替代
CREATE TABLE ... SELECT：先用CREATE TABLE ... LIKE复制结构（不含数据、不触发 DML），再用独立INSERT ... SELECT插入（单事务、单 GTID） - 替代存储过程内建临时表：改用普通表 + 命名空间前缀（如
tmp_<code>proc_id_xxx），配合DROP TABLE IF EXISTS清理；确保引擎为 InnoDB - 检查所有依赖对象：运行
SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db';，确认无 MyISAM 表残留
真正难排查的，永远是那些没出现在你写的存储过程代码里、却藏在触发器或视图定义中的非事务引擎引用。
