SQL Server 中的嵌套查询或临时 (#) 表

Cat*_*key 5 performance sql-server best-practices

我编写了一个 Web 应用程序,它聚合并呈现来自 SQL Server 的数据。涉及的数据量很大,涉及的聚合也比较多。目前,在“专家”的建议下,我使用了包括聚合在内的大量嵌套查询,但是我刚刚在这里阅读了有关通过将大型复杂查询分解为临时 (#) 表来优化大型复杂查询的信息。这似乎与许多表明使用临时表不是最佳实践的文献相冲突。

Web 应用程序本身将被相当多的人使用,因此理想情况下,如果他们需要索引,我不希望临时表相互冲突。

查询优化的最佳方法是什么,以及广泛使用的网络应用程序的最佳实践是什么?

提前致谢。

厘米

gbn*_*gbn 7

SQLCat 团队的想法和文章有时会针对大多数人在给定负载或数据库大小的情况下永远不会看到的边缘情况。

话虽如此,他们给出的想法有提高性能的通用技术(例如将OR更改为UNION)

临时表在存储过程编译等方面存在一些问题,但不要将它们与表变量混淆(SQLCat 文章中提到了这一点)。此外,临时表应该是本地的而不是全局的,以便单独的进程不会相互影响

就个人而言,我经常使用临时表来分解查询:但并非总是如此。如果我可以在一个运行良好的 SQL 语句中完成它(因为它的使用频率),那么我将使用它。

在您的情况下,我会确定一些问题查询,并查看使用临时表是否更适合这些查询。如果您看不到任何问题查询,那么什么都不做。

  • 临时表对 tempDB 的影响如何?那么使用表变量而不是临时表呢? (3认同)
  • @Oded:无论如何,中间结果和聚合都将在 tempdb 中进行假脱机和处理,因此除了表分配/解除分配外,没有太大变化。但这仅在每秒数十或数百次时才重要(http://sqlskills.com/BLOGS/PAUL/post/Misconceptions-around-TF-1118.aspx)。表变量有索引和统计问题:参见 SO (http://stackoverflow.com/search?q=temp+table+table+variable) 和 dba.se 进行比较。SQLCat 文章说不要使用它们 (3认同)