MySQL临时表引擎切换由内存限制和版本决定：5.7及以前超限自动切MyISAM，8.0+默认改用InnoDB，MyISAM需手动启用且受限；关键在控制是否落地，优先调大tmp_table_size和max_heap_table_size。
临时表引擎切换由内存限制和MySQL版本共同决定
MySQL 创建临时表时不会固定用某一种引擎，而是先尝试 MEMORY，失败后才降级到磁盘引擎——这个“失败”主要看 tmp_table_size 和 max_heap_table_size 中的较小值是否被突破。一旦超限，就触发降级，而降级目标在 5.7 和 8.0+ 之间完全不同。
MySQL 5.7 及以前：超限自动切到 MyISAM
这是因为当时 MyISAM 是唯一被默认启用、无需事务支持、建表快、索引轻量的磁盘引擎。它不写 redo/undo 日志，临时表高频创建销毁时 I/O 更干净；key_buffer_size 还能单独调优，不跟 InnoDB 的缓冲池争资源。
- MyISAM 不支持事务，但临时表本就不该参与事务一致性保障
-
TEXT/BLOB字段会让MEMORY表直接落地，而 MyISAM 是当时少数能承载这类字段的轻量磁盘引擎 - 表级锁在临时表场景几乎无影响——每个 session 的临时表天然隔离
MySQL 8.0+：默认改用 InnoDB，MyISAM 需手动启用且可能失败
8.0 默认禁用 MyISAM（skip_myisam=ON），系统表全转 InnoDB，CREATE TEMPORARY TABLE ... ENGINE=MyISAM 会直接报错：Unknown storage engine 'MyISAM'。即使你显式配置启用，8.0.16 起也移除了 MyISAM 的全文索引支持，若临时表依赖 MATCH AGAINST 就走不通。
- InnoDB 作为磁盘临时表更安全：有崩溃恢复、MVCC、行级锁，适合现代混合负载
- 代价是写入略重——要写 redo log，临时表多时 I/O 压力会上升
- 若真需要 MyISAM 行为，必须在启动前确认
skip_myisam=OFF，且不能依赖全文检索
真正关键的不是选哪个引擎，而是控制是否落地
多数性能问题其实出在临时表被迫写磁盘，而不是落地后用了 InnoDB 还是 MyISAM。你应该优先检查并调大 tmp_table_size 和 max_heap_table_size（二者取小值生效），尤其当查询含 GROUP BY、ORDER BY 或大结果集时。MyISAM 在 8.0 下已不是“选项”，而是“例外”，且这个例外需要主动解锁、主动承担风险。
