临时表默认引擎由@@session.default_storage_engine决定，非全局配置；显式指定ENGINE=InnoDB可规避MyISAM的可靠性风险，但需同步调大tmp_table_size和max_heap_table_size，并注意事务回滚影响。
临时表默认引擎受会话级设置控制，不是全局配置决定的
很多人以为设了 innodb_default 就万事大吉，结果 CREATE TEMPORARY TABLE 还是生成 MyISAM 表。根本原因是：MySQL 临时表引擎由 @@session.default_storage_engine 决定，而非全局变量。某些 ORM（如旧版 Django）或连接池会在建连后执行 SET SESSION default_storage_engine = 'MyISAM'，悄悄覆盖你的预期。
验证方式很简单：SELECT @@session.default_storage_engine;。如果返回 MyISAM，哪怕全局是 InnoDB，临时表照样走磁盘文件、不支持事务、崩溃后残留损坏风险高。
安全做法永远是显式声明：CREATE TEMPORARY TABLE t1 (...) ENGINE=InnoDB;，不依赖任何会话状态。
MyISAM 临时表在大查询中容易静默失败或报错
典型现象包括：ERROR 1169 (23000): Duplicate entry '' for key 'PRIMARY'（明明没主键）、ERROR 1034 (HY000): Incorrect key file for table、甚至直接断连。这不是性能问题，而是可靠性崩塌。
原因很实在：
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- MyISAM 临时表仍依赖磁盘上的
.MYD/.MYI文件，不支持崩溃恢复 - 查询被 kill、OOM 杀掉进程、或
tmpdir空间不足时，临时文件极易残留或索引损坏 - InnoDB 临时表走的是
ibtmp1共享临时表空间，所有操作受 redo 日志保护，异常中断也能自动清理
尤其当查询含 GROUP BY、ORDER BY、UNION 或嵌套子查询时，MySQL 可能多次创建/销毁临时表，MyISAM 的开销和失败概率呈指数增长。
MySQL 8.0 已强制禁用 MyISAM 临时表，5.7 是最后兼容窗口期
MySQL 8.0 直接移除了 MyISAM 作为临时表引擎的支持能力，显式写 ENGINE=MyISAM 会报错：ERROR 1286 (42000): Unknown storage engine 'MyISAM'。这意味着：如果你现在还在 5.7 上依赖 MyISAM 临时表，升级到 8.0 时存储过程、ETL 脚本、报表 SQL 都会批量报错。
更隐蔽的风险是变量作用域变化：SELECT id INTO @last_id 后跟 CREATE TEMPORARY TABLE，在 InnoDB 模式下可能让 @last_id 变成 NULL——这不是 bug，而是 MySQL 8.0+ 严格事务隔离 + 语句块作用域导致的副作用。提前改用 DECLARE last_id BIGINT DEFAULT 0; 才能平滑过渡。
显式指定 ENGINE=InnoDB 并非万能，要注意两个硬限制
强制用 InnoDB 临时表前，必须确认两件事：
-
tmp_table_size和max_heap_table_size要足够大，否则大结果集仍会退化为磁盘临时表（哪怕引擎是 InnoDB） - 若查询涉及
FULLTEXT索引或某些地理函数，InnoDB 的实现与 MyISAM 不同，比如中文分词需启用ngram插件，innodb_ft_min_token_size默认为 2，而 MyISAM 是 4
最易被忽略的一点：InnoDB 临时表参与事务回滚。以前用 MyISAM 临时表做中间计算，ROLLBACK 后数据还在；换成 InnoDB 后，ROLLBACK 会清空它——逻辑行为已变，不能只改引擎，还得审代码路径。
