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

我正在编写一个数据库前端，到目前为止，它依赖于客户端UI和数据库之间的数据访问层。作为一个SQLNoob（而且由于这不是一个高安全性的应用程序），我很高兴使用DAL作为在存储过程中编写所有数据库逻辑的替代方案

我现在关心的是速度。我知道SQL Server编译存储过程并执行它们的速度比随机查询快得多，但我找不到任何关于这对性能有多大影响的信息

我知道，如果我在设计SQL Server，我至少会考虑透明地缓存常见查询，以及根据需要动态存储和编译程序来容纳公共查询。我认为这将在许多场景中基本上消除对存储过程的需求（显然，除了封装数据库）

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

---

另一方面，SELECT的性能如何随表格大小而变化？我似乎找不到这方面的任何资源，但它似乎对决定如何布局我的数据库至关重要。比如说，我是将所有条目都推到一个表中，并依赖于在逻辑组中将它们隔离在何处，还是将条目分组到单独的表中，因为从一百万行中选择100行非常慢？

如果使用正确的参数化查询（使用

@CustomerID

等参数，而不是将SQL语句连接在一起），存储过程和普通SQL语句之间应该没有太大区别。普通查询和存储过程的执行计划都是由SQL Server缓存的，如果经常使用，它们不会太快从缓存中抛出。因此，严格地说，从性能角度看，存储过程不会我会给你很多好处

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

至于表大小：如果您有适当的索引，一个简单的索引查找操作将在SQL Server中进行大约3-6次页面读取，以达到叶子级别，这最多可用于数百万个数据页。要点是：适当的索引，这并不总是容易做到的

SQL Server中最重要的一个方面是获得正确的聚类索引，因为它定义了数据的物理顺序，而聚类键是服务器中复制最多/冗余最多的数据块，因此您希望尽可能提高效率

查看Kimberly Tripp的优秀博文，并研究她链接到的其他博文，以更好地理解什么是一个好的聚类键-这对正确操作绝对至关重要

---

SQL Server上的索引女王金伯利（Kimberly）也发表了大量关于如何选择好的非聚集索引的博文，以及当“少即是多”（也不要为数据库编制过多的索引，这可能比根本没有索引更糟糕）

，就我所知，只要你有一个

[int]标识（1,1）如果聚集索引不为NULL，则符合Kimberly Tripp列出的所有标准。@icc97:完全正确-这就是为什么
INT-IDENTITY
是最适合SQL Server表的主键/聚集键之一