SQL Server性能：什么是更快，存储过程或视图？

Question

SQL Server 2005/2008，存储过程或视图的速度有多快？

修改 正如你们许多人指出的那样，我太模糊了。让我试着更具体一点 我想知道View中特定查询的性能差异，而不是存储过程中的完全相同的查询。 （我仍然感谢所有指出其不同能力的答案）

Answer 1

存储过程（SP）和SQL视图是本文中多次提到的不同“野兽”。

如果我们排除与查询计划缓存相关的一些[通常是次要的，除了边缘情况]性能考虑因素，与绑定到存储过程相关的时间等，这两种方法完全等效表现明智。然而......

视图仅限于可以在单个SELECT语句中表达的任何内容（好吧，可能还有CTE和其他一些技巧），但一般情况下，视图与声明形式的查询相关联 。另一个存储过程可以使用各种过程类型构造（以及声明式构造），因此，使用SP，可以手工制作解决给定查询的方法这可能比SQL-Server的查询优化器可能做得更高效（基于单个声明性查询）。在这些情况下，SP可能会快得多（但要注意......优化器非常智能，并且使SP比同等视图慢得多）。

除了这些性能考虑外，SP还具有更多功能，允许比视图更广泛的查询和操作。

Answer 2

不幸的是，他们不是同一种野兽。

存储过程是一组T-SQL语句，CAN返回数据。它可以执行各种逻辑，也不一定返回结果集中的数据。

视图是数据的表示。它主要用作具有底层连接的一个或多个表的抽象。它始终是零行，一行或多行的结果集。

我怀疑你的问题更像是：

  

哪个更快：SELECT来自视图，或者存储过程中的等效SELECT语句，给定相同的基表执行具有相同where子句的连接？

Answer 3

这不是一个真正的问题，因为答案在所有情况下都适用。但是，作为SQL Server特定实现的一般答案...

通常，存储过程很可能比直接SQL语句更快，因为服务器在第一次保存和执行存储过程时会执行各种优化。

视图本质上是一个保存的SQL语句。

因此，我会说，一般来说，存储过程可能比视图更快，如果每个SQL语句的SQL语句相同，并且如果SQL语句可以从优化中受益。否则，一般来说，它们的表现会相似。

参考这些链接文档，支持我的回答。

http://www.sql-server-performance.com/tips/stored_procedures_p1.aspx

http://msdn.microsoft.com/en-us/library/ms998577.aspx

此外，如果您正在寻找优化SQL Server性能的所有方法，那么上面的第二个链接是一个很好的起点。

Answer 4

我更喜欢存储过程，因为允许更好地控制数据，如果你想构建一个好的，安全的模块化系统然后使用存储过程，它可以运行多个sql命令，具有控制流语句并接受参数。您可以在视图中执行的所有操作都可以在存储过程中执行。但是在存储过程中，您可以更灵活地进行操作。

Answer 5

简而言之，根据我在一些复杂查询中的经验，存储过程提供了比函数更好的性能。

但是你不能在select或join查询中使用存储过程的结果。

如果您不想在另一个查询中使用结果集，最好使用SP。

本论坛和其他地方的人们提到了其他细节和差异。

Answer 6

我认为另一种思维方式是使用存储过程来选择视图。这将使您的架构成为松散耦合的系统。如果您决定在将来更改架构，您将不必担心它会破坏前端。

我想我所说的不是sp vs views，而是思考sp和观点：）

Answer 7

存储过程和视图不同，具有不同的用途。我将视图视为固定查询。我将存储过程看作代码模块。

例如，假设您有一个名为tblEmployees的表，其中包含以下两列（{1}}和DateOfBirth。

名为MaleFemale的视图仅过滤掉男性员工，这非常有用。名为viewEmployeesMale的视图也非常有用。这两种观点都是自我描述的，非常直观。

现在，假设你需要列出25到30岁之间所有男性雇员的名单。我倾向于创建一个存储过程来产生这个结果。虽然它肯定可以构建为一个视图，但在我看来，存储过程更适合处理这个问题。日期操作尤其是空值是一个因素可能变得非常棘手。

Answer 8

观看次数：

• 我们可以在视图上创建索引（在存储的proc中是不可能的）
• 很容易给出抽象视图（仅对多个表的有限列访问） 表数据发送给其他DBA /用户

存储过程：

• 我们可以将参数传递给sp（在视图中是不可能的）
• 在过程中执行多个语句（例如插入，更新，删除操作）

Answer 9

其他一些注意事项：虽然SP和视图之间的性能基本相同（假设它们执行完全相同的选择），SP会为同一查询提供更大的灵活性。

• SP将支持对结果集进行排序;即包括ORDER BY语句。你不能在视图中这样做。
• SP已完全编译，只需要一个exec来调用它。该视图仍需要SELECT * FROM view来调用它;即，在视图中对已编译的选择进行选择。

Answer 10

我知道我不应该把这变成一个＆＃34;讨论＆＃34;但我对此非常感兴趣，只是想我分享我对a的经验观察特定情况，特别是上面的所有注释，其中声明从存储过程和视图中执行的等效SELECT语句应具有大致相同的性能。

我在数据库中有一个视图＆＃34; A＆＃34;它在一个单独的数据库中连接5个表（db＆＃34; B＆＃34;）。如果我附加到db＆＃34; A＆＃34;在视图中的SSMS和SELECT *中，返回250000行需要> 3分钟。如果我从视图的设计页面中获取select语句并直接在SSMS中执行它，则需要＆lt; 25秒在执行该过程时，将相同的select语句放入存储过程会产生相同的性能。

没有对绝对性能进行任何观察（db＆＃34; B＆＃34;是一个我们不允许触摸的AX数据库！），我仍然绝对相信在这种情况下使用SP是一个命令比使用View检索相同数据更快，这适用于此特定情况下的许多其他类似视图。

我不认为它与创建与其他数据库的连接有什么关系，除非使用视图它以某种方式永远不能缓存连接而选择确实因为我可以在同一个SSMS窗口中反复切换2个选项，并且每个查询的性能保持一致。另外，如果我直接连接到db＆＃34; B＆＃34;并运行select而不使用dbname.dbo .... refs，它需要相同的时间。

有人想过吗？

Answer 11

找到了详细的性能分析：https://www.scarydba.com/2016/11/01/stored-procedures-not-faster-views/

编译时间比较：

  

视图本身与存储过程之间的编译时间有所不同（它们几乎相同）。让我们看一下数千次执行时的性能：

     

查看AVG：210.431431431431

     

具有View AVG的存储过程：190.641641641642

     

存储的Proc AVG：200.171171171171

     

这是用微发送来衡量的，所以我们看到的变化可能只是I / O，CPU或其他方面的一些差异，因为差异在10mc或5％上很小。

关于执行时间（包括编译时间）如何？ 差异：

  

查询时长查看AVG：10089.3226452906

     

存储的Proc AVG：9314.38877755511

     

使用View AVG存储的产品：9938.05410821643

结论：

  

除了编译时间上的差异外，如果所查询的内容相同，我们看到的是视图实际上与存储过程完全相同。