mysql 8.0 中无法强制内部临时表只在内存中创建，因 memory 引擎不支持 text/blob 且超限直接报错，而 temptable 支持按需分页落盘，配合 temptable_max_ram 等参数可智能控盘。
MySQL 8.0 中无法强制内部临时表“只在内存中创建”——这是设计上的根本限制，强行压制落盘会引发报错或静默降级，反而更慢。
为什么 internal_tmp_mem_storage_engine = MEMORY 不再可靠
MySQL 8.0.16 起，默认值已改为 TEMPTABLE，而旧式 MEMORY 引擎仍存在硬约束：不支持 TEXT/BLOB、行长度固定、超 max_heap_table_size 直接报 ERROR 1114 (HY000): The table is full，且不会自动转磁盘。一旦查询涉及任意一个 TEXT 字段或大结果集，MEMORY 就会直接失败，而不是“尽力内存化”。
- 显式设
internal_tmp_mem_storage_engine = MEMORY后，遇到GROUP BY CONCAT(name, ' ', email)这类操作，大概率触发ERROR 1163 -
tmp_table_size和max_heap_table_size对MEMORY是硬上限；但对TEMPTABLE仅间接影响初始内存池分配 - 即使你把所有参数拉到 2G，只要单行含
TEXT，MEMORY就不可用——这不是配置问题，是引擎能力边界
真正可控的内存优先策略：用 TEMPTABLE + temptable_max_ram
目标不是“禁止落盘”，而是让落盘行为更智能、更少发生。TEMPTABLE 的设计就是按需分页落盘（page-level spilling），而非整表刷盘，配合合理参数可大幅减少磁盘 I/O。
- 必须显式设置：
internal_tmp_mem_storage_engine = TEMPTABLE（即使默认已是，也建议写死，避免版本/配置继承干扰） - 核心调优参数是
temptable_max_ram（默认1G），它决定内存池总上限；超过此值的新页才写入磁盘临时文件（.ibt） -
tmp_table_size和max_heap_table_size应设为相等值（如256M），且 ≤temptable_max_ram，否则 TEMPTABLE 可能跳过内存池直走磁盘路径 - 容器或内存紧张环境加
temptable_use_mmap = OFF，防止 mmap 占用过多虚拟地址空间导致 OOM
验证是否真走内存，别信参数值
改完配置重启后，光看 SELECT @@internal_tmp_mem_storage_engine 返回 TEMPTABLE 不代表生效——得看实际行为。
- 执行典型语句：
SELECT user_id, COUNT(*) FROM orders GROUP BY user_id; - 立刻查状态：
SHOW STATUS LIKE 'Created_tmp%';，重点关注Created_tmp_disk_tables增速是否明显低于之前 - 用
EXPLAIN FORMAT=TREE看执行计划，若显示Using temporary但无Using filesort，且rows_examined增长平缓，说明内存页内处理高效 - 检查
information_schema.innodb_temp_table_info，有记录但TABLE_SCHEMA为空、TABLE_NAME为innodb_temp开头，即为优化器创建的 TEMPTABLE 实例
容易被忽略的兼容性断点
TEMPTABLE 表面平滑，但底层变更可能暴露旧代码假设：
- 某些 UDF 或存储过程若硬编码依赖
MEMORY的“无 BLOB”特性，切换后可能因字段类型不符报错 - 监控脚本若只 grep
Created_tmp_tables而忽略Created_tmp_disk_tables，会误判优化效果 -
ORDER BY RAND()类查询仍会触发Using temporary，但此时是 TEMPTABLE + rowid 排序，性能比老版 MEMORY 更稳，别急着加索引 - 临时表文件（
temp_*.ibt）默认落在datadir/#innodb_temp/，若该目录所在磁盘慢或满，temptable_max_ram再大也白搭
