将代码封装在存储过程中

  实际上，在你的SQL Server应用程序中使用的所有T-SQL代码都应该被封装在存储过程中，而不应作为动态SQL或脚本来运行。这不仅会降低网络流量，而且会加速T-SQL执行，因为服务器上存储过程中的代码已经被预编译。在编写存储过程时要想获得最优性能，需牢记以下几点。

  当一个存储过程第一次被执行时，它会被优化，一个查询计划被编译并缓存在SQL Server内存中。如果相同的存储过程被再次调用，它将不会在创建一个新查询计划，而是使用缓存的计划，这会节省时间、提高性能。这可能并非一直都是你所希望的。如果存储过程中的该查询每次都完全相同，那么这是一件好事。但是如果查询是动态的（例如WHERE子句可能会有所不同），那么这将非常糟糕，因为查询运行时不会再给优化，该查询的性能可能会受影响。如果你知道存储过程中的查询每次运行时会有所不同，那么在你创建存储过程时，你可以考虑增加WITH RECOMPILE选项。这将会强制存储过程每次运行时需要重新编译。

  记住在你的存储过程中增加“SET NOCOUNT ON”这个声明。如果你没有打开这个功能，那么每次一个SQL语句被执行是，SQL Server将会发送一个响应给客户端，显示该语句所影响的行数。实际上客户端一般不需要这个信息。使用这个声明可以有助于减少服务器和客户端之间的通信。

  为避免在你的SQL Server应用程序中发生死锁现象，按照以下建议来设计你的应用程序：1、应用程序每次按照相同的顺序来访问服务器对象；2、在事务处理过程中，不允许任何用户输入。在事务处理开始前对其进行收集；3、保持事务处理简短且在一个单一批处理中。

  如何选择索引来最优化数据库性能

  对于许多SQL Server数据库管理员和开发者来说，索引选择是一件神秘的事情。当然，我们知道它们可以做什么以及它们如何提高性能。问题在于如何选择理想类型的索引（聚集索引还是非聚集索引），以及需要索引的列的数量（是否需要对多个列进行索引），和哪一个列应该被索引。

  在这一部分中，我们将就如上问题给出简短的答案。不过，这些答案并不一定适合每一种情景。与大多数SQL Server性能调优和优化一样，你必须进行一些试验来发现最理想的索引。下面让我们先开始看看一些通用的索引创建规则，然后详细的看一下如何选择聚集和非聚集索引。

  索引有可能是坏事吗？是的。有的人认为只要把所有一切都索引，然后所有性能问题就会被解决。事实并非如此。索引可以加速数据访问，但是如果它被不合适的选择，同样也会降低数据访问。

  索引过多所带来的问题是，每次一条记录被插入、删除或更新操作时，SQL Server必须对索引进行维护。维护1、2个索引或许不会给SQL Server带来太大开销，但是如果你的索引在5个以上，这可能会给数据表带来较大的性能负担。理想情况下，索引应该越少越好。为了获得最优化性能，选择合适的索引数需要你掌握好一个平衡的度。

  大概来说，只有你确信真正需要添加索引的时候，才对表添加索引。你必须非常了解对数据所进行的查询类型，然后根据这些信息选择合适的索引，索引创建后，必须通过测试来查看它是否真正可以提高性能。

  对于OLTP应用来说，选择非常好的索引通常比较困难，因为这类应用通常要进行大量的插入、更新和删除行为。尽管你需要好的索引来迅速定为那些需要进行插入、更新或删除操作的记录，但是如果索引太多，会使得每一次操作带来太大的开销。另一方面，如果你有一个仅对数据库进行只读操作的OLAP应用，那么你可以根据自己的需要来尽可能多的添加索引。由此可见，你的应用程序使用方式不同，会给你的索引建立策略带来很大差别。

  还有两种情况，索引不会给你的SQL Server带来性能上的提高，一是数据表非常小、记录非常少的情况下；二是被索引的列有超过95%以上的数值不是唯一的。这两种情况下SQL Server查询优化器不会使用你选择的索引，因此它们对SQL Server是一个负担，需要删除之。