Question

一般来说，对于组合大量数据，最好使用临时表/临时变量作为临时区域，还是应该坚持使用“UNION ALL”？

假设：

无需进一步处理，结果将直接发送给客户。
客户端等待完整的记录集，因此不需要流式传输结果。

Answer 1

我会坚持UNION ALL。如果不需要进行中间处理，因此需要临时表，那么我就不会使用。

将数据插入临时表（即使它是一个表变量，尽管有神话，但不是纯粹的“内存”结构）将涉及tempdb中的工作（这可能是一个瓶颈）。然后只需SELECT * as-is并返回它而不需要任何特殊处理是不必要的，我认为膨胀代码。当你只需要在没有任何特殊处理的情况下返回数据时，临时表方法似乎有点“围绕房屋”。如果我认为有理由使用临时表，我会运行一些类似的性能测试来与没有临时表的vs进行比较 - 然后比较统计数据（持续时间，读取，写入，CPU）。进行实际的性能测试是尽可能自信的最佳方式，无论您选择哪种方法，都是最好的。特别是因为您不必使用临时表将工作推送到tempdb中 - 即根据您的查询，它可能涉及到tempdb中的工作。

澄清一下，我并不是说一个比另一个更好。与大多数事情一样，这取决于场景。在所描述的场景中，它只是听起来你要添加一个似乎没有添加任何功能值的额外步骤，除了创建稍微复杂/冗长的查询之外，我看不到你获得任何东西。

Answer 2

我可以想到的临时表的一个优点是你可以对它们应用索引。因此，在处理大量需要尽快恢复结果的数据时，这应该会有所帮助。

Answer 3

对于它的价值，我只是在两种检索相同数据集的方法之间进行了性能比较：

SELECT c1, c2, c3 FROM ... ON ... WHERE
UNION ALL
SELECT c1, c2, c3 FROM ... ON ... WHERE /*(repeated 8 times)*/

VS

CREATE TABLE #Temp (c1 int, c2 varchar(20), c3 bit)
INSERT INTO #Temp (c1, c2, c3) SELECT (c1,c2,c3) FROM ... WHERE... /*(repeat 8 times)*/
SELECT c1, c2, c3 FROM #Temp

第二种方法（临时表）比联合慢约5％，当我人为地扩大重复次数时，第二种方法变得更慢。

Answer 4

并非特定于联合所有..

使用临时表可能具有并发POV的优势，具体取决于查询，隔离级别和客户端/网络链接的性能，其中使用临时表可以最大限度地减少读取锁定时间。只是不要使用SELECT ..INTO ..来创建表。

在一般情况下，UNION ALL避免了不必要的工作表的开销。

Answer 5

我倾向于只使用UNION ALL，其中我的UNIONS数量有限 - 并且返回的列数相对有限，表类型变量是另一种可能性（特别是2014年） - 并允许您强制执行结构的通用性类似的结果集构建在多个位置。

UNION ALL避免了中间步骤，但是： 1）它可能导致臃肿，难以维护的代码 2）它可能导致无法管理的查询计划 - 如果它们变得太大，那么sql server中的计划查看工具实际上无法查看它们 3）如果复杂联合的部分是相似的，或者可能在系统的其他地方使用，请考虑使用表值函数或存储过程以便重新使用代码，无论您是使用TTV，UNION ALL还是临时表

SQL Server：临时表或联合更好吗？

5 个答案: