事务中执行create temporary table报错，是因为enforce_gtid_consistency=on时，mysql为保障gtid复制安全，禁止在事务上下文中创建或删除临时表，因其会话绑定特性无法在从库重放。
CREATE TEMPORARY TABLE 在事务中被拒绝，是因为 GTID 要求事务可重放，而临时表只存在于当前会话、不写入 binlog、无法在从库重建上下文。只要 enforce_gtid_consistency=ON，MySQL 就会直接拦截这类操作。
为什么事务里执行 CREATE TEMPORARY TABLE 会报错？
错误信息通常是：ERROR 1786 (HY000): Statement violates GTID consistency: CREATE TEMPORARY TABLE and DDL are not allowed with GTID。这不是语法问题，而是复制安全机制的硬性拦截。
- GTID 复制依赖“一个事务 → 一个 GTID → 可幂等重放”；临时表生命周期绑定连接，从库没有相同会话，无法还原其存在状态
-
@Transactional方法会自动开启BEGIN/COMMIT，把CREATE TEMPORARY TABLE包进显式事务块，触发检查 - 即使你没写
BEGIN，只要 autocommit=0（Spring 默认），后续语句就处于隐式事务中，同样被拦
CREATE TEMPORARY TABLE 什么情况下能用？
它本身没被禁用，只是不能出现在事务边界内。关键看执行时是否处于事务上下文、以及 MySQL 版本和 binlog 格式。
- MySQL 8.0.13+：当
binlog_format = ROW或MIXED时，允许在存储过程/函数中创建临时表（因为不写 binlog） - 所有版本：只要不在任何事务中（即 autocommit=1 且未手动
BEGIN），单独执行CREATE TEMPORARY TABLE是安全的 - 注意：
DROP TEMPORARY TABLE同样受限制，不能放在事务里；会话断开时自动清理，一般无需显式 drop
Spring Boot 中怎么绕过这个限制？
核心思路是把临时表操作剥离出事务范围，避免 Spring 的 @Transactional 把它卷进去。
- 拆分逻辑：先在非事务方法里建临时表（
jdbcTemplate.execute("CREATE TEMPORARY TABLE ...")），再调用@Transactional方法处理业务逻辑 - 不要用
autocommit=0连接执行临时表语句；确认数据源配置或连接池参数没强制关闭 autocommit - 替代方案：用普通表 + 唯一后缀（如
tmp_report_20260702_12345）代替临时表，但需自行清理，注意并发冲突
CREATE TABLE ... SELECT 和临时表限制是一回事吗？
不是同一机制，但根源相似：都因 GTID 要求“事务原子性”与语句实际执行行为冲突。
-
CREATE TABLE ... SELECT在 8.0.21 前会被拆成 DDL + DML 两个逻辑单元，可能分配不同 GTID；8.0.21+ 靠原子 DDL 日志支持单事务完成，仅限 InnoDB 表 - 临时表限制至今未取消——它本质是会话级对象，与事务边界天然不兼容；MySQL 不可能让从库“模拟”主库会话状态
- 两者报错代码不同：
ERROR 1786（临时表） vsERROR 1787（CREATE TABLE SELECT）
gtid_mode=ON，只要 autocommit=1 且没 BEGIN，CREATE TEMPORARY TABLE 就能跑通。很多排查卡在“以为 GTID 全局禁用”，其实只是事务包裹方式不对。
