我应该使用临时表吗？答案

【问题标题】：Should I use a temp table?我应该使用临时表吗？
【发布时间】：2011-09-08 08:38:14
【问题描述】：

我有一个报告查询需要 4 分钟，但低于我们所允许的最长 30 秒限制。

我注意到它有很多 INNER JOINS。一个，我明白了，它连接到一个有数百万行的 Person 表。我想知道分解查询是否会更有效。这样做会更有效吗：

假设所有键都被索引。表 C 有 800 万条记录，表 B 有 600 万条记录，表 A 有 400,000 条记录。

SELECT Fields
FROM TableA A
INNER JOIN TableB B
ON b.key = a.key
INNER JOIN Table C
ON C.key = b.CKey
WHERE A.id = AnInput

或者

SELECT *
INTO TempTableC
FROM TableC
WHERE id = AnInput

-- TempTableC 现在有 1000 条记录那么

SELECT Fields
FROM TableA A
INNER JOIN TableB B --Maybe put this into a filtered temp table?
ON b.key = a.key
INNER JOIN TempTableC  c
ON c.AField = b.aField
WHERE a.id = AnInput

基本上，将结果集放入临时表中，然后加入。

【问题讨论】：

如果可以的话，请贴出慢查询的执行计划。
6-8 百万条记录并没有那么大，也不应该对正确索引的表造成问题。我经常处理 4 亿条记录表，这些表在查询中表现得很好。
提供的执行计划将深入了解实际性能开销发生的位置，并验证正确的索引使用情况。请分享。
谢谢伙计们——明天会收到的。提供给您的最佳方式是什么？
@cdotlister - 获取图形计划的屏幕截图并将其作为图像上传，或获取文本计划，然后您可以将其粘贴为“报价”文本块。

标签： sql sql-server

【解决方案1】：

如果您的 Person 表索引正确，则 INNER JOIN 应该不会导致此类问题。检查您是否在所有表中连接的列上创建了索引。将临时表用于看似相对简单的查询似乎掩盖了数据库设计不足的问题。

正如其他人所说，唯一确定的方法是发布您的查询计划。

【讨论】：

您可以通过获取查询计划来做到这一点。
它归结为一个非常愚蠢的子查询，它正在为每一行运行....感谢您的帮助。