我的BI开发人员写了一个查询，花了14个小时来运行，我正试图帮助他。在高层次上，它是一个查询，探索过去15年的金融交易，并将其分解为每个季度。
我在这里分享我已经给他的答案，但我想知道你是否有任何建议，我们可以进一步探索和研究，以提高性能，答案如:"也许你可能想看看快照…">
他的查询包含:
- 包括使用多个视图，这意味着从一个视图中选择生成另一个视图等。
- 一些视图连接三个表，每个表大约有1 - 2亿行。
- 某些视图使用子选择查询。
以下是我到目前为止的建议:
- 不要使用嵌套视图来生成查询，而是使用视图为每个视图创建新表，因为数据不是动态的(金融交易数据)并且不会更改。从我的经验来看，嵌套视图对性能不利。
- 不使用子查询，尽可能使用JOIN。
- 我确保他在适当的地方创建非集群索引。 当有这么多数据时，不要使用TEMPT表。
- 尝试在JOIN中使用的所有表上使用WITH(NO LOCK)
- 查找通用查询并将其转换为存储过程
- 当连接这三个大表(1 - 2亿行)时，尝试将数据量限制在
JOIN，而不是使用WHERE。例如，代替select * from tableA JOIN tableB WHERE…使用SELECT *从表a连接表b上的....并为多。日期之间范围。这将在稍后的查询中与其他表连接时提供更少的数据。
问题是他必须处理的数据太大了，我想知道查询性能只能做这么多，因为在一天结束的时候，你仍然需要在查询中处理所有这些数据。也许下一步是考虑如何准备这些数据并首先将它们存储在更小的表中，例如CostQ1_2010, CostQ2_2020等……然后根据所有这些表编写查询。
你给我们的信息太少了。托尔斯泰写道:"所有幸福的家庭都是相似的;不幸的家庭各有各的不幸。"SQL查询也是如此，尤其是大型BI查询。
我将冒险回答一些一般性的问题。
对于您提到的大小的表，您的查询肯定包含日期范围WHERE过滤器，如transaction_date >= something AND transaction_date < anotherthing。一般来说，一份有用的报告涵盖了十年中一年的交易。因此，请确保您有正确的索引，以便在可能的情况下进行索引范围扫描。如果您选择显示实际执行计划功能，SSMS有时会建议使用索引。
学习阅读执行计划
阅读覆盖索引。他们有时会产生很大的影响。
在开始这种长时间运行的历史BI查询之前使用语句SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED。BI查询和数据库上的其他活动之间的干扰会更少。
从BI查询中使用的视图中预加载一些非规范化的表可能是有意义的。