Question

我一直致力于一个解决方案（在SQL Server中），其中所有没有异常的子查询都已使用临时表重写，以提高性能。

举个例子，所有的查询都是这样的：

SELECT something 
FROM (SELECT * FROM T1 WHERE condition1) 
JOIN ...

已被重写为：

SELECT * 
INTO #tempTable 
FROM T1 
WHERE condition1

SELECT something 
FROM #tempTable  
JOIN ...

还建议here应避免所有子查询，以支持临时表。

根据给定的事实，是否应该用临时表替换所有子查询？如果不是，何时应该考虑另一个？

Answer 1

这太荒谬了。一个笑话。

你的“子查询”很好。 SQL Server只是忽略它。您可以将其重写为：

SELECT something
FROM T1 JOIN . . .
WHERE condition1

SQL Server应该正确优化它。

根据我使用SQL Server的经验，极少数情况下需要创建临时表来优化查询。更常见的是，我使用查询提示来避免嵌套循环连接。

如果需要一个临时表，那么表上几乎总会有索引。这是使用临时表的关键原因之一。（另外两个是因为通过一个查询或多个查询重复相同的查询块。）

Answer 2

在关于子查询的讨论中，我经常看到的一点是人为因素，特别是嵌套对象的可读性和代码的可维护性。

与其他形式的人类可读代码一样，运行和编辑查询的人员必须了解他们正在运行的内容以及查询的不同部分之间如何交互，这一点很重要。除了仅检索和传递几个元素的简单子查询外，日益复杂的子查询可能变得更加难以阅读和理解查询（以及查询与超级查询的关系），并且由于除了解查询所花费的时间以外的其他原因，可能更难以维护（例如，如果嵌套中涉及大量代码重复）。

此外，从简单的子查询开始的内容可能会扩展并变得更加复杂，这时您可能必须将子查询提取到临时表中才能使其可读/处理真正的性能问题（ Gordon Linoff提到了）。根据团队成员对这种重构的适应程度以及使用子查询（例如存储过程）对脚本的依赖程度，这种可能需要花费更多时间进行重构的可能性可能意味着经理会将临时表引入为样式偏好和“性能提升”一样。

是否应该用临时表替换所有子查询？

2 个答案: