TempTable引擎是MySQL 8.0+内存临时表的默认实现，相比MEMORY引擎支持TEXT/BLOB、动态行格式（省30%~50%内存）、按页落盘不中断、并发锁优化；其真实性能取决于temptable_max_ram参数设置、索引覆盖及是否禁用temptable_use_mmap。
TempTable 引擎本身不比“内存临时表”更快——它就是 MySQL 8.0 中内存临时表的实现方式。 说它“更快”，其实是对比老版本 MEMORY 引擎在相同场景下的实际表现：更少落盘、更省内存、更稳并发。真瓶颈不在引擎名字，而在你是否用对了参数、是否触发了隐式降级。
为什么 internal_tmp_mem_storage_engine = MEMORY 在 8.0 下反而容易变慢
MEMORY 引擎在 MySQL 8.0 中并未被移除，但它已不是默认，且有硬性限制：
- 遇到
TEXT或BLOB字段直接报错ERROR 1163，查询中断；而 TempTable 用 off-page 方式管理，照样走内存 - 行格式固定，
VARCHAR(255)存一个字符也占满 255 字节；TempTable 支持动态行格式，实测节省 30%~50% 内存 - 超
max_heap_table_size就ERROR 1114，不自动落盘；TempTable 超temptable_max_ram后按页写磁盘临时文件，查询不崩只是变慢 - 高并发下多个会话争抢同一块内存池，锁冲突明显；TempTable 内置轻量级锁和内存池分片，争抢更少
temptable_max_ram 才是真正控制内存上限的关键参数
MySQL 8.0+ 中，tmp_table_size 和 max_heap_table_size 对 TempTable 引擎**不直接生效**，它们只间接影响其内存分配策略。真正决定“能用多少内存”的是：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
temptable_max_ram：默认 1GB，表示 TempTable 引擎整个内存池上限。超过此值，新页直接 mmap 到磁盘临时文件（路径由tmpdir控制） - 如果
tmp_table_size和max_heap_table_size中较小值 >temptable_max_ram，那 TempTable 会提前降级——哪怕数据量没超 1GB，也可能因策略冲突被迫落盘 - 验证方法：
SELECT @@temptable_max_ram, @@tmp_table_size, @@max_heap_table_size;，三者需协同设置，推荐设为相同值（如都设 268435456 即 256MB）
GROUP BY / ORDER BY 场景下，TempTable 的“快”依赖索引，不是调参
很多人以为把 temptable_max_ram 调到 4G 就能解决慢查询，结果发现 Created_tmp_disk_tables 还在涨——因为根本问题不在内存，而在执行路径：
- 没有覆盖索引的
GROUP BY a, b，MySQL 必须读全表建临时表分组；加INDEX(a,b)后可能直接流式聚合，连临时表都不需要 -
ORDER BY x LIMIT 10无索引，必触发Using filesort + Using temporary；加索引后排序下推，跳过临时表 - SELECT 中包含大字段（如
body TEXT）会迫使 TempTable 部分数据 off-page，虽不报错但 I/O 增加；应考虑只查必要字段或用延迟关联
监控时别只盯 Created_tmp_disk_tables
这个状态变量只统计“最终落到磁盘的临时表数量”，但 TempTable 的按页落盘行为会让它严重滞后于真实压力：
- 一个 1.2GB 的 GROUP BY 查询，
temptable_max_ram = 1G，它只会生成 1 个磁盘临时表，但实际已产生 200MB 磁盘 I/O - 更敏感的指标是
SHOW GLOBAL STATUS LIKE 'Innodb_data_waits%'或perf top -p $(pgrep mysqld)看 mmap/write 系统调用占比 - 错误日志里出现
Writing temp table to disk或Using external sort是比状态变量更早的信号
真正让 TempTable “显得快”的，是它把原本会中断或卡死的场景，变成了可预测、可监控、可渐进优化的路径。但如果你的查询本身没索引、字段冗余、并发乱设 session 参数，再好的引擎也救不了。最常被忽略的一点：TempTable 的性能收益，90% 取决于你有没有关掉 temptable_use_mmap —— 容器环境或低内存机器上，mmap 会悄悄吃掉大量虚拟地址空间，导致 OOM 杀进程而非优雅降级。
