临时表仅在分组前需多次过滤、连接或计算且数据量大时可能加速GROUP BY；简单聚合反而因额外写入开销变慢，关键取决于是否减少重复扫描或冗余计算。
临时表真能加速 GROUP BY 吗？先看这三种情况
不能一概而论。只有当分组前需多次过滤、连接或计算中间结果，且数据量大、逻辑重复时，CREATE TEMPORARY TABLE 才可能提速；如果只是简单 GROUP BY + 聚合函数，加临时表反而多一次写入开销。
常见误判点：把“SQL 写得长”等同于“适合拆成临时表”。实际上，是否受益取决于执行计划里是否出现重复扫描或冗余计算。
- 适合：子查询被引用 2 次以上，且含
WHERE+JOIN+CASE组合 - 不适合：单次
SELECT COUNT(*) FROM t GROUP BY a, b - 危险信号：临时表没加索引，但后续
GROUP BY字段又不在主键里
怎么建临时表才不拖慢整体性能
核心原则：只存必要字段，建好立刻加索引，避免全表扫描反成瓶颈。
MySQL 的 CREATE TEMPORARY TABLE 默认用 MEMORY 引擎（内存表），但一旦超出 max_heap_table_size 会自动转成 MyISAM 磁盘表——这时 I/O 成为新瓶颈，比原 SQL 还慢。
- 显式指定引擎：
CREATE TEMPORARY TABLE tmp AS SELECT ... ENGINE=InnoDB（尤其数据 >10MB） - 建完立刻建索引：
CREATE INDEX idx_group ON tmp (user_id, status)，别等GROUP BY时再依赖隐式排序 - 避免
SELECT *：只SELECT user_id, status, amount这类实际参与分组或聚合的列 - 注意字符集：临时表若含中文字段，却用
latin1，后续JOIN可能触发隐式转换，索引失效
GROUP BY 前用临时表 vs CTE，哪个更稳
MySQL 5.7 不支持写入 CTE，8.0+ 虽支持 WITH，但优化器对 CTE 的物化策略不透明——有时反复执行，有时缓存，难以预测。
临时表行为确定：建完就落盘/内存，后续语句查它就是查一张真实表，可控性强。
- CTE 优势：语法简洁，适合只读、轻量中间结果（如
WITH top_users AS (...) SELECT ... FROM top_users GROUP BY ...） - 临时表优势：可加索引、可
UPDATE/DELETE、可复用多次，适合复杂清洗链路 - 兼容性坑：
CREATE TEMPORARY TABLE在存储过程里有效，但在某些 ORM（如 Django raw SQL）中需确认连接未复用导致表名冲突
为什么加了临时表反而变慢？重点检查这三处
不是临时表本身有问题，而是使用方式触发了隐式惩罚机制。
-
tmp表没主键或唯一约束，GROUP BY字段又无索引 → 全表扫描 + 文件排序（Using filesort） - 临时表数据量远超
tmp_table_size和max_heap_table_size→ 频繁磁盘落盘，SHOW STATUS LIKE 'Created_tmp_disk_tables'持续上涨 - 在事务里建临时表后，又执行了
ROLLBACK→ MySQL 临时表生命周期绑定会话，但部分驱动（如旧版 PyMySQL）可能未正确清理连接，导致下次执行报Table 'tmp' already exists
临时表不是银弹，它的价值藏在「减少重复计算」和「让优化器看清数据分布」这两件事上。漏掉索引、盲目物化、忽略内存限制，都会让它从加速器变成减速带。
