SQL-Server 性能：存储过程或视图哪个更快？

Question

SQL Server 2005/2008、存储过程或视图中哪个更快？

编辑：正如你们中的许多人指出的那样，我太含糊了。 让我尝试更具体一点。
我想知道视图中特定查询与存储过程中完全相同查询的性能差异。 （我仍然感谢所有指出它们不同功能的答案）

Answer 1

正如这篇文章中多次提到的，存储过程 (SP) 和 SQL 视图是不同的“野兽”。

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

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

除了这些性能考虑之外，SP 更通用，并且允许比视图更广泛的查询和操作。

Answer 2

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

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

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

我怀疑你的问题更多的是：

这是更快： SELECT从视图荷兰国际集团，或等效的SELECT在存储过程中的语句，给予相同的基表具有相同的where子句进行连接？

Answer 3

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

通常，存储过程比直接 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

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

但是您不能在选择或联接查询中使用存储过程的结果。

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

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

Answer 6

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

我想我说的不是 sp 与视图，而是 sp 和视图 :)

Answer 7

存储过程和视图是不同的，具有不同的用途。 我将视图视为预设查询。 我将存储过程视为代码模块。

例如，假设您有一个名为tblEmployees的表，其中包含以下两列（以及其他列）： DateOfBirth和MaleFemale 。

一个名为viewEmployeesMale的视图可以非常有用，它只过滤掉男性员工。 名为viewEmployeesFemale的视图也非常有用。 这两种视图都是自我描述的并且非常直观。

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

Answer 8

我知道我不应该把它变成一个“讨论”，但我对此很感兴趣，只是想分享我对特定情况的经验观察，特别参考上面所有的评论，这些评论指出从存储过程和视图中执行的等效 SELECT 语句应该具有大致相同的性能。

我在数据库“A”中有一个视图，它在一个单独的数据库（db“B”）中连接了 5 个表。 如果我附加到 SSMS 中的 db "A" 并从视图中选择 *，则需要 3 分钟以上才能返回 250000 行。 如果我从视图的设计页面中取出 select 语句并直接在 SSMS 中执行它，则需要 < 25 秒。 当我执行该过程时，将相同的 select 语句放入存储过程会产生相同的性能。

在没有对绝对性能进行任何观察的情况下（db "B" 是一个我们不允许接触的 AX 数据库！），我仍然绝对相信在这种情况下使用 SP 比使用视图要快一个数量级检索相同的数据，在这种特殊情况下，这适用于许多其他类似的视图。

我认为这与创建到另一个数据库的连接没有任何关系，除非通过使用视图，它以某种方式永远无法缓存连接，而选择缓存，因为我可以在同一个 SSMS 窗口中的 2 个选择之间反复切换和每个查询的性能保持一致。 此外，如果我直接连接到 db "B" 并在没有 dbname.dbo .... refs 的情况下运行选择，则需要相同的时间。

有人有什么想法吗？

Answer 9

意见：

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

店铺流程：

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

Answer 10

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

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

Answer 11

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

编译时间比较：

视图本身和存储过程之间的编译时间存在差异（它们几乎相同）。 让我们看看几千次执行的性能：

查看平均：210.431431431431

存储过程带视图 AVG：190.641641641642

存储过程平均：200.171171171171

这是以微发送来衡量的，因此我们看到的变化可能只是 I/O、CPU 或其他方面的一些差异，因为差异在 10mc 或 5% 时微不足道。

包括编译时间在内的执行时间怎么样，因为有区别：

查询时长查看AVG：10089.3226452906

存储过程平均：9314.38877755511

存储过程带视图 AVG：9938.05410821643

结论：

除了编译时间的不同，我们看到视图实际上与存储过程完全相同，如果有问题的查询是相同的。