为什么MySQL 8.0中TempTable引擎比内存临时表执行更快-mysql教程-PHP中文网

TempTable引擎是MySQL 8.0+内存临时表的默认实现，相比MEMORY引擎支持TEXT/BLOB、动态行格式（省30%~50%内存）、按页落盘不中断、并发锁优化；其真实性能取决于temptable_max_ram参数设置、索引覆盖及是否禁用temptable_use_mmap。

为什么mysql 8.0中temptable引擎比内存临时表执行更快

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 引擎**不直接生效**，它们只间接影响其内存分配策略。真正决定“能用多少内存”的是：

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 还在涨——因为根本问题不在内存，而在执行路径：

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

没有覆盖索引的 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 杀进程而非优雅降级。