临时表在 MySQL 执行计划里是怎么被触发的
MySQL 不会主动创建临时表供你显式使用，而是优化器在特定场景下自动选择
TEMPTABLE或
MEMORY引擎来缓存中间结果。是否走临时表，取决于执行计划中是否出现
Using temporary—— 这个标记出现在
EXPLAIN的
Extra列里，是唯一可靠的判断依据。
常见触发场景包括：
–
GROUP BY和
ORDER BY字段不一致（如
GROUP BY a ORDER BY b）
– 多表
JOIN时连接键无索引，且需要去重或排序
– 子查询返回结果集后参与外层
DISTINCT或聚合
– 窗口函数（如
ROW_NUMBER()）在未命中索引排序时
MEMORY 临时表 vs On-disk 临时表怎么选
MySQL 默认优先用
MEMORY引擎建临时表，但有两个硬性条件不满足就会退化为磁盘表（
InnoDB或
MyISAM）：
– 单行长度超过
max_heap_table_size（注意：不是
tmp_table_size，后者仅控制初始分配上限）
– 表中包含
TEXT、
BLOB、
JSON或超过 512 字符的
VARCHAR字段
这两个值都可动态调整，但要注意：
max_heap_table_size必须 ≤
tmp_table_size才有效，否则以较小者为准 调高后不会立即释放内存，只影响新创建的临时表 磁盘临时表默认写入
tmpdir，若该路径在系统盘且并发高，I/O 成为瓶颈
如何避免不必要临时表（实操建议）
多数性能问题来自“本可避免却没避开”的临时表。关键不是调大内存参数，而是让优化器绕过它：
确保GROUP BY和
ORDER BY使用相同字段顺序，且这些字段有联合索引（如
INDEX(a,b)支持
GROUP BY a,b ORDER BY a,b） 对
JOIN条件字段补索引，尤其右表连接键；避免
SELECT *带来隐式宽表，导致超
max_heap_table_size用
LIMIT配合子查询提前截断数据量，例如把
(SELECT ... FROM huge_table) t JOIN small_table s改成
(SELECT ... FROM huge_table LIMIT 1000) t JOIN ...检查
SQL_BIG_RESULT提示是否误加——它会强制走磁盘临时表，即使数据很小
监控与诊断临时表开销
光看
EXPLAIN不够，得结合运行时指标定位真实压力点：
SHOW GLOBAL STATUS LIKE 'Created_tmp%';
重点关注：
Created_tmp_tables：内存临时表数量
Created_tmp_disk_tables：磁盘临时表数量（理想比值应
Created_tmp_files：磁盘临时表使用的临时文件数（过高说明频繁落盘）
如果
Created_tmp_disk_tables持续上升，别急着调参，先查
slow_query_log里带
Using temporary的慢 SQL，再用
EXPLAIN FORMAT=TRADITIONAL看具体哪一步触发——有时候只是某个
CASE WHEN表达式导致字段类型升级为
TEXT，就足以让整个临时表落地。
临时表真正的复杂点不在语法或参数，而在于它是个“隐形决策”：优化器根据统计信息、索引覆盖度、字段类型隐式推导出是否需要它。一旦推导错误，调参只是掩盖症状。
