SQL性能优化：临时表关联查询应如何创建索引提升运行效率？

一、单列索引和联合索引的选择 #

你需要根据临时表关联列的实际使用场景判断：

• 如果你的查询每次仅使用临时表的单个列作为关联键，选择独立单列索引即可。
  你给出的示例查询中，临时表#tempKeys仅用AddrId和Address表关联，PhoneId是Address表的关联列，不属于临时表的关联字段，这种场景下只需要给临时表的AddrId建单列非聚集索引就足够。如果后续还有其他查询需要用到临时表的其他列单独做关联，再对应给每个列单独建索引即可，每个单列索引都可以独立生效。
• 只有当你存在同一个查询同时使用临时表的多个列作为关联/过滤条件的场景时，才需要创建联合索引。创建联合索引需要遵循最左前缀匹配原则，将区分度最高、使用频率最高的列放在索引最左侧。
  如果你错误创建了(AddrId, PhoneId)的联合索引，但实际没有同时用这两个列做关联/过滤的场景，那当你单独用PhoneId做关联时，这个联合索引无法生效，反而会额外占用临时表存储空间、增加临时表写入的开销。

二、其他性能优化方案 #

• 先确认临时表建索引的必要性：如果临时表数据量小于1万行、且仅做一次关联查询，不需要建索引，建索引的开销可能高于查询节省的时间。只有临时表数据量大、后续需要多次关联查询时，建索引才划算。
• 优先选择聚集索引：如果临时表的Id是唯一值，直接创建聚集主键性能远高于非聚集索引，语句参考：

  CREATE CLUSTERED INDEX PK_tempKeys ON #tempKeys (Id)
  

  如果关联列AddrId的重复度很低，也可以直接将聚集索引建在关联列上，关联查询效率更高。
• 做索引覆盖优化：如果你的查询仅需要返回临时表的少数几个字段，可以在索引中包含这些字段，避免回表查询开销，示例语句：

  CREATE NONCLUSTERED INDEX IX_tempKeys_AddrId ON #tempKeys (AddrId) INCLUDE (Id, Name)
  

• 检查实体表的索引：很多时候慢查询的瓶颈不在临时表，而在关联的实体表，你需要确认Address表的AddrId、Phone表的PhoneId上已经建了索引，避免实体表全表扫描。
• 去掉不必要的DISTINCT：如果关联逻辑不会产生重复数据，删除DISTINCT可以省掉排序去重的大量开销。
• 调整索引创建顺序：先往临时表插入全部数据，再创建索引，不要先建索引再插入数据，后者会大幅增加临时表写入的开销。

内容的提问来源于stack exchange，提问作者user16318579