SQL Multiple View-On-View，然后使用联合查询 [关闭]

Question

我将两个 SQL Server 密集查询合并在一起。

我对 SQL 相当陌生，因此我使用多个视图来准备数据。

VIEW 1                                    VIEW A
      |                                        |
VIEW 2 (Grouping View 1)                  VIEW B (Grouping View A)

              \                                /
               UNION VIEWS 2B  (JOINING VIEW 2 AND B)
                              |
                        VIEW 3 (Grouping View 2B)                    ANOTHER VIEW C
                                        \                                  /
                                        UNION VIEW 3C (JOINING VIEW 3 AND C)

当我进入 View 3C 时，大约有 400 万行数据和 52 列。当我从 SQL Server Management Studio 运行视图时，有时会收到“TIME EXPIRED ERROR”。有时它运行得很好，但开始输出数据大约需要 10 分钟。

如果我在 Excel 中将查询运行到数据透视表中，它有时会运行，有时会失败。

数据每周三更新一次，大约有30人刷新数据。

所以我还是 SQL 新手，想知道可以建议的不同方法。是否有一组中间视频可以提供帮助？

Answer 1

使用临时表还是使用更复杂的查询是一个见仁见智的问题，这两种方式各有利弊。 SQL Server 有一个非常好的优化器，所以它通常可以很好地优化复杂的查询。它还支持查询提示（Postgres，你在听吗？）。根据我的经验，带有偶尔查询提示的 SQL Server 优化器已足以实现性能。

另一方面，有些人更喜欢使用临时表。而且，当它们不被用作拐杖时，它们肯定会有所帮助。例如，您可以在临时表上构建索引，这可以大大提高性能。此外，如果您在查询中多次使用子查询，则 SQL Server 会重新创建它们，而不是存储结果并重新使用结果（Microsoft，您在听吗？）。例如，甚至没有编译器提示来实现 CTE。

我发现使用临时表会导致代码复杂。它需要为表分配名称并确保在重新运行查询时正确更新它们。多年来，我花了很多时间调试由于中间表没有正确更新而引起的问题（这是我倾向于不使用它们的主要原因）。

最后，我认为观点不是正确的方法。视图在第一次运行时由 SQL 引擎编译。如果数据发生变化，那么执行计划可能不会改变——然后查询计划就不是最优的了。当基础数据可能以可能影响查询计划的方式发生变化时，您需要小心处理视图（以及存储过程和函数中的查询）。

如果您是 SQL 新手，那么您的查询可能并不复杂，您应该获得更复杂查询的经验。