MySQL临时表默认引擎由查询复杂度和配置决定，非用户可控；含GROUP BY等操作或超内存限制时自动降级为磁盘表，且MEMORY不支持TEXT/BLOB；应通过EXPLAIN和状态变量监控，并合理调优tmp_table_size与max_heap_table_size。

临时表到底该用 MEMORY 还是 InnoDB？

MySQL 临时表默认引擎取决于查询复杂度和配置，不是你想用啥就用啥。当查询含 GROUP BY、ORDER BY、窗口函数或大结果集时，MySQL 会自动把内存临时表（MEMORY）降级为磁盘临时表（InnoDB 或 MyISAM），哪怕你显式指定 ENGINE=MEMORY 也没用。

• tmp_table_size 和 max_heap_table_size 必须同时调大，且两者取较小值作为单个临时表的内存上限
• 超过这个值，哪怕只是多一行数据，就会无声切换到磁盘，性能断崖下跌
• MEMORY 引擎不支持 TEXT/BLOB 类型，一旦 SELECT 中有这类字段，直接走磁盘
• InnoDB 临时表虽慢些，但支持事务、行锁、大字段，稳定性高得多

示例：执行 SELECT ... GROUP BY long_text_column，即使加了 WHERE 限制行数，只要 long_text_column 是 TEXT，就必然落地磁盘。

如何确认你的查询真正在用临时表？

别猜，看 EXPLAIN 和状态变量。重点盯两个信号：

• EXPLAIN 输出中出现 Using temporary，说明优化器决定建临时表；但这不等于“用了内存表”，它只表示“需要中间结构”

• 查看会话级变量：SHOW STATUS LIKE 'Created_tmp%';
   • Created_tmp_tables：磁盘临时表数量
   • Created_tmp_disk_tables：真正落到磁盘的数量
   • 如果后者接近前者，说明内存限额太低或数据类型不兼容

• 开启 performance_schema 后，查 performance_schema.events_statements_summary_by_digest 可定位哪类 SQL 频繁触发临时表

  

  MySQL8 CRM Schema Design Expert

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

  下载

• 注意：UNION、派生表（FROM (SELECT ...)）、CTE（WITH）默认都走临时表，哪怕结果只有几行

临时表能被索引加速吗？怎么加？

能，但方式受限。显式创建的临时表（CREATE TEMPORARY TABLE）可以像普通表一样加索引；而隐式临时表（优化器自建）完全不可控，无法加索引，只能靠改写 SQL 让它少干活。

• 显式临时表示例：

  CREATE TEMPORARY TABLE tmp_user_ids (
  user_id BIGINT PRIMARY KEY,
  score INT
  ) ENGINE=InnoDB;
  INSERT INTO tmp_user_ids SELECT user_id, score FROM users WHERE status = 1;

  这样后续 JOIN 就能走主键索引
• 隐式场景下，想提速就得“提前过滤”：比如把 WHERE 条件尽量推到子查询最外层，避免在临时表上做全量 GROUP BY
• ORDER BY 字段如果没索引，临时表排序开销极大；若必须排序，考虑在源表上建联合索引覆盖排序+查询字段
• 不要试图在 MEMORY 表里建 BTREE 索引——它只支持 HASH，且仅对等值查询有效

tmp_table_size 调多大才安全？

没有统一答案，得看你的最大单次聚合结果集大小。盲目调高反而危险：

• 设置超过物理内存的 20%～30%，可能引发系统 OOM，尤其在并发高时
• max_heap_table_size 必须和 tmp_table_size 保持一致，否则以小的为准
• 生产环境建议从 64M 起步，观察 Created_tmp_disk_tables / Created_tmp_tables 比值，目标压到 5% 以下
• 注意：该配置是会话级的，SET SESSION tmp_table_size = 134217728 只影响当前连接，不影响其他连接

临时表性能问题从来不在“要不要用”，而在“能不能避免生成大临时表”。最有效的优化，往往是把一个大聚合拆成多次小查询，或者用物化视图/汇总表预计算——临时表只是兜底方案，不是银弹。