是的，CREATE TEMPORARY TABLE 不触发隐式提交，可在事务中安全执行，ROLLBACK 能撤销其创建；而普通 DDL（如 CREATE TABLE、ALTER TABLE）均会强制隐式提交当前事务。
CREATE TEMPORARY TABLE 真的不触发隐式提交吗
是的，CREATE TEMPORARY TABLE 是 MySQL 中极少数明确**不触发隐式提交**的 DDL 语句。它能在显式事务中安全执行，后续 ROLLBACK 仍会撤销该临时表的创建（注意：不是“删除”，而是整个创建动作被回滚）。
但这只适用于 TEMPORARY 表——普通表的 CREATE TABLE 会立刻提交当前事务，且无法回滚。
- 临时表仅对当前会话可见，会话断开时自动销毁，因此 MySQL 将其设计为“事务友好的 DDL”
- 即使在
autocommit = 1模式下，CREATE TEMPORARY TABLE也不会导致未提交的 DML 被强制落盘 - 验证方式：执行
BEGIN→INSERT→CREATE TEMPORARY TABLE t AS SELECT 1→ROLLBACK→ 再查原表，INSERT数据消失，临时表也不存在
为什么其他 DDL 都要隐式提交，唯独临时表例外
根本原因在于语义隔离：临时表不修改数据库元数据（mysql 系统库中的 tables、columns 等表），也不影响其他会话的可见性或复制逻辑。它的生命周期完全绑定于会话内存上下文，无需写 binlog 或持久化到数据字典。
而所有非临时的 DDL（如 ALTER TABLE、CREATE INDEX）必须更新全局元数据、刷新表定义缓存、同步到从库，这些操作天然无法回滚，所以 MySQL 强制在执行前提交当前事务。
-
CREATE TEMPORARY TABLE不写 binlog（除非显式开启binlog_format=ROW并设置log_bin_trust_function_creators=1，但即便如此，它仍不触发隐式提交） - 它不持有 MDL（metadata lock）全局锁，不会阻塞其他会话对同名非临时表的操作
- InnoDB 层不为其分配独立的表空间，仅在内存中维护结构描述
容易踩的坑：你以为在事务里，其实已经不在了
很多开发者误以为只要没写 COMMIT，整个会话就“还在一个事务里”。但 MySQL 的事务边界其实很脆弱——一次隐式提交后，新语句就进入下一个事务了，哪怕你没写 START TRANSACTION。
- 在事务中混用
CREATE TABLE和INSERT：前者一执行，前面的INSERT就已落盘，ROLLBACK对它无效 - 用
LOCK TABLES做读锁保护？它也会触发隐式提交，等价于提前COMMIT - 在存储过程中调用
CREATE TEMPORARY TABLE后继续 DML，要注意：如果过程本身被DECLARE CONTINUE HANDLER捕获异常并ROLLBACK，临时表会被销毁，但 DML 是否回滚取决于事务状态是否已被破坏
真正安全的事务内建表方案
如果你需要在事务中动态构造中间结果，并希望它随事务原子性消亡，CREATE TEMPORARY TABLE 是唯一可靠选择。但要注意它和事务的耦合点：
- 它不能跨会话共享，所以别指望用它做“轻量级物化视图”供其他连接查询
- 它不支持外键约束（MySQL 9.6.0 虽将外键上移到 SQL 层，但临时表仍不参与外键检查）
- 如果事务中先
CREATE TEMPORARY TABLE t，再DROP TEMPORARY TABLE t，这个DROP不触发隐式提交，但表已不可用——这不是 bug，是设计使然
临时表的“事务安全”只体现在创建动作可回滚，不意味着它能替代事务型 DML 的一致性保障。真要多步强一致，还是得靠 START TRANSACTION 包裹常规表操作，把 DDL 拆到事务之外单独执行。
