存储过程和SQL Server 2008性能的好处

Question

到目前为止，我正在编写一个数据库前端，它依赖于客户端UI和数据库之间的数据访问层。 作为SQL菜鸟（并且由于这不是一个高安全性的应用程序），我对DAL感到满意，因为DAL可以替代在存储过程中编写所有数据库逻辑的方法。

我目前关心的是速度。 我知道SQL Server会比随机查询更快地编译存储过程并执行它们，但是我找不到任何有关此过程实际上对性能有多大影响的信息。

我知道，如果我正在设计SQL Server，则至少要考虑透明地缓存常见查询，以及根据需要动态存储和编译过程以适应常见查询。 我想这将在许多情况下大大消除对存储过程的需要（显然，除了封装数据库外）。

但是目前我的数据库很小，因此我无法真正判断它的性能如何。 我在这里走错了路吗？ 一旦数据库增长到数百万条记录，并且发现自己的方式错误，我是否会痛苦地将所有逻辑迁移到存储过程？

与此相关的是，SELECT的性能如何随表大小而缩放？ 我似乎找不到任何资源，但是决定如何布置数据库似乎至关重要。 我是将所有条目都推到一个表中，还是依靠WHERE将它们隔离在逻辑组中，还是将条目分组到单独的表中，因为从一百万行中选择100个行太慢了？

Answer 1

如果您使用正确的参数化查询（使用@CustomerID之类的参数，而不是将SQL语句串联在一起），则存储过程和普通SQL语句之间应该不会有太大区别。 普通查询和存储过程的执行计划都由SQL Server缓存，并且如果经常重复使用它们，则不会太快地从缓存中删除它们。 因此严格来说，从性能的角度来看，存储过程并没有真正给您带来太多好处。

存储过程可以是有益的，因为它们可以提供另一层安全性-如果您所有的数据访问都通过存储过程进行，那么“常规”用户通常甚至不需要对基表的读取权限。

至于表的大小：如果您有适当的索引编制，那么简单的“索引查找”操作将需要在SQL Server中进行大约3-6页的读取才能达到叶级-最多可容纳数百万个数据页。 关键是： 正确的索引编制并不总是那么容易且显而易见。

SQL Server中最重要的方面之一就是正确确定群集索引 ，因为它定义了数据的物理顺序，并且群集键是服务器中复制最多/冗余程度最高的数据片段-因此您希望将其设置为尽可能高效。

查阅Kimberly Tripp出色的博客文章《群集密钥的更多注意事项》 ，并研究她链接到的其他博客文章，以更好地理解什么是好的群集密钥-这对正确使用至关重要 ！

金伯利-SQL Server上的索引女王 -关于如何选择良好的非聚集索引以及何时减少索引（也不要过度索引数据库），也有大量精彩的博客文章（甚至可能比没有索引更糟糕）完全没有）