关联临时表为何大幅降低我的SQL查询性能？

嘿，这个问题我碰到过好多次了，结合你提到的数十万数据量、Key1-Key6以及测试用的KeyB字段，关联临时表变慢通常逃不开这几个核心原因，咱们一个个说清楚：

1. 临时表大概率没加合适的索引 #

临时表默认是不会自动生成索引的（除非你建表时显式指定）。想象一下：你的主表有数十万条数据，关联时数据库要把主表的每一条记录，和临时表的所有记录挨个比对——这就像在一本没有目录的厚书里找特定内容，速度能快才怪！

如果你的关联字段是KeyB，那建临时表时一定要给它加索引，比如：

CREATE TEMPORARY TABLE temp_table (
  id INT,
  KeyB VARCHAR(50),
  -- 其他字段...
  INDEX idx_temp_keyb (KeyB)
);

2. 临时表的统计信息拖了优化器的后腿 #

数据库的查询优化器全靠统计信息选最优执行计划，但临时表的统计信息往往要么缺失，要么完全不准：

• 比如MySQL这类数据库，对临时表的统计信息收集非常滞后，优化器可能误以为临时表只有几条数据，直接选了嵌套循环连接这种适合小表的策略，但实际临时表数据量不小，结果就是执行计划彻底跑偏。
• 有些数据库甚至根本不给临时表生成统计信息，优化器只能“瞎猜”，自然选不出哈希连接、合并连接这类高效的关联算法。

3. 临时表的存储机制拖了后腿 #

不同数据库的临时表存储逻辑差别很大，这也容易导致性能问题：

• 比如MySQL里，如果临时表的数据量超过tmp_table_size或max_heap_table_size的限制，会直接从内存表转成磁盘表——磁盘IO的速度比内存慢好几个数量级，关联时性能直接跳水。
• 要是临时表用了MyISAM这类老旧引擎，它的锁机制、缓存策略都不如InnoDB适合关联查询，也会拖慢整体速度。

4. 临时表本身的数据质量有问题 #

如果你的临时表是通过复杂聚合、子查询生成的，可能存在大量重复数据，或者KeyB这类关联字段的数据分布极不均匀——比如某个KeyB值占了临时表一半的数据，那主表每一条匹配这个值的记录，都要和临时表的几万条数据比对，耗时自然飙升。

给你的几个快速优化建议 #

• 给临时表的关联字段必加索引，别省这一步；
• 手动更新临时表的统计信息（比如MySQL用ANALYZE TABLE temp_table;），帮优化器选对执行计划；
• 临时表只保留关联需要的字段和数据，别把无关字段都塞进去，尽量缩小数据量；
• 尽量让临时表用和主表一致的存储引擎（比如InnoDB），避免引擎差异带来的性能损耗。

内容的提问来源于stack exchange，提问作者Lightness Races in Orbit