我正在编写一个数据库前端，到目前为止依赖于客户端UI和数据库之间的数据访问层。作为一个SQL noob（因为这不是一个高安全性的应用程序），我很高兴DAL作为在存储过程中编写所有数据库逻辑的替代方法。
我现在关注的是速度。我知道SQL Server将编译存储过程并比随机查询更快地执行它们，但我找不到任何关于这实际对性能有多大影响的信息。
我知道如果我在设计SQL Server，我至少会考虑透明地缓存常见查询，以及根据需要动态存储和编译程序以容纳常见查询。我想这很可能在很多场景中消除了对存储过程的需求（显然，除了封装数据库之外）。
但目前我的数据库非常小，所以我无法确定它的表现如何。我在错误的道路上吗？一旦数据库增长到数百万条记录，我会最终痛苦地将所有逻辑迁移到存储过程吗？我发现了错误的方法吗？
在相关的说明中，SELECT的性能如何与表大小一起缩放？我似乎无法找到任何资源，但决定如何布置我的数据库似乎至关重要。我是否将所有条目推送到一个表中，并依赖WHERE将它们隔离在逻辑组中，或者我将条目分组到单独的表中，因为选择100个行中的100个非常慢？
答案 0 :(得分：4)
如果使用正确的参数化查询（使用@CustomerID之类的参数而不是将SQL语句连接在一起），则存储过程和纯SQL语句之间应该没有太大区别。 SQL Server都缓存了普通查询和存储过程的执行计划，如果它们经常被重复使用，它们就不会被过快地抛出缓存。因此从性能角度来看，存储过程实际上并没有给您带来太多好处。
存储过程可能是有益的，因为它们可以提供另一层安全性 - 如果所有数据访问都通过存储过程进行，“常规”用户通常不需要基表的读取权限。
至于表大小：如果你有适当的索引，一个简单的索引搜索操作将在SQL Server中进行大约3-6页的读取以达到叶级 - 这就是多达数百万个数据页。重点是：正确编制索引，并且要做到这一点并不总是那么容易和明显。
SQL Server中最重要的一个方面是正确获取集群索引，因为它定义了数据的合理顺序，而集群密钥是最复制/最冗余的数据块。你的服务器 - 所以你想让它尽可能高效。
查看Kimberly Tripp的优秀博客文章More Considerations For The Clustering Key，并研究她链接到的其他博客文章，以便更好地了解什么是良好的群集密钥 - 这是绝对至关重要走吧！
Kimberly-- SQL Server上的索引女王 - 也有很多关于如何选择好的非聚集索引的博客文章，以及当 less is more 时不要过度索引你的数据库 - 这可能比根本没有索引更糟糕了