SQL Server 2005 视图与物化视图与存储过程

Posted 2023-02-26

【中文标题】SQL Server 2005 视图与物化视图与存储过程

【英文标题】：SQL Server 2005 View vs Materialized View vs Stored Procedure

【发布时间】：2009-09-11 20:42:41

【问题描述】：

如果我有一个表，其中包含多个位置的数万条帐户记录。

如果我查询一个选择特定位置的所有帐户的视图和一个使用相同 SQL 语句的存储过程，是否有任何速度差异？

编辑：我遇到了这个物化视图。似乎总是会使用它。

您希望何时使用存储过程、视图和实体化视图？在做出此决定时，您希望牢记哪些利弊？

【参考方案1】：

简短回答：“视情况而定”

更长的答案：“这取决于查询的形状”

与任何有关 SQL Server 性能的问题（哪个更好：x 与 y）一样，没有正确答案。在视图与存储过程的情况下，除了分析查询之外，没有办法可靠地预测哪个（如果有的话）更快。

我发现两者都更快，这取决于视图的使用方式以及它是否是更大查询的一部分。我还看到视图会降低查询速度，因为它们可以隐藏使用视图的查询实际上不需要的许多复杂性。

您需要评估您想要实现的目标：如果您所做的只是想要访问表行，并且您不想将输出用作另一个查询的一部分，我会选择一个存储过程，特别是如果针对表的查询将使用一些 WHERE 子句。

将从哪里调用查询？ SQL 的另一部分？一些应用框架？自定义数据访问层？调用代码如何将查询放在一起是值得考虑的，因为这会影响 SQL Server 最终缓存和重用执行计划的方式。如果它只是将一堆动态 SQL 连接在一起，那么性能可能会受到轻微影响，因为 SQL Server 可能每次都需要重新构建查询计划；所以在这种情况下，sproc 具有缓存计划的优势。如果接入层是智能的，做参数化的动态SQL，可能就没有那么多了。

结论：了解您想要实现的目标。然后分析、调整、调整并重复，直到满意为止。

【参考方案2】：

视图和存储过程都被编译到数据库中，因此它们比直接查询更快，当您需要动态参数时，它们之间的速度差异就会出现。意见只是不接受他们。

每个人都有自己的特定用途。视图可以在其他查​​询或视图中使用，存储过程只能被执行。但是在您的问题中，使用相同的 SELECT * FROM 它们具有完全相同的速度。

【讨论】：

SQL Server 中没有“编译到数据库”。来自视图的查询、过程和临时查询在编译计划的速度、编译和缓存方面都将完全相同，只要它们具有相同、相同的定义。

【参考方案3】：

是和不是。

视图是一个查询定义，在使用时基本上就地替换，它被编译到引用视图的查询中。这意味着实际执行取决于引用视图的查询。如果查询是直截了当的SELECT * FROM view，那么这将是与等效过程几乎完全相同的执行计划。但是，如果查询是 SELECT onefield FROM view，则查询显着不同。没有等效的过程，由于减少了投影列表，此查询可能会执行得更好。

还有巨大的可用性差异。只能执行存储过程。可以从 和 中选择一个视图，并与多个其他语句（如连接、子查询等）一起使用。

鉴于视图具有更好的灵活性，除非没有其他因素起作用，否则只有在您有参数时程序才有意义，因为视图不能有参数。

【讨论】：

如果您需要参数，但想要视图的其他优点，例如“从多个其他语句中选择并与连接...一起使用”，那么表值用户定义函数应该是考虑。

【参考方案4】：

对此Post 的回答将提供有关 SQL Server 中索引（物化）视图的有用背景。

【参考方案5】：

我还看到每个都比另一个更快，具体取决于上下文。

我遵循的一般经验法则是：如果视图具有复杂的 WHERE、依赖于其他中等复杂的视图或者是 UNION [ALL] 的结果，那么几乎可以肯定 SQL S 将无法正确执行将应用于视图的 WHERE 条件一直传播到各个表，因此在某一时刻，您将开始获取表扫描（除非它是物化视图），否则您的执行计划将比他们的执行计划复杂得多（而且速度慢）可能是。

在这些情况下，最好选择 proc。正如其他人所说，永远是个人资料！