只访问所需要的数据

  尽管这个建议听起来很简单，实现起来却很难，在很多SQL Server应用程序中，这是一个非常常见的性能相关的问题。通过以下思路，可以减少返回客户端的数据量。

  不要返回非必须的更多行或列数据给客户端。这会加大磁盘I/O开销和网络流量，都会影响性能。在SELECT语句中，不要使用SELECT *来返回行数据，只根据你的需要来返回需要的列。在多数情况下，务必要包含WHERE条件子句来降低返回数值或行的数量。

  如果你的应用允许用户运行查询，但是你又不能防止用户返回数千行、数万行非必须的数据，可以考虑在SELECT语句中使用TOP运算符。这样，你可以限制返回行的数量。

  避免使用游标（Cursors）

  T-SQL擅长处理结果集，而并非单条记录。这时候游标有了用武之地。它们让你可以处理单条记录。单条记录处理的唯一问题是非常慢。理想情况下，对于高性能SQL Server应用程序来说，应尽量避免使用游标。

  如果你需要实现逐行操作，尽量使用另一种方法来完成这个任务。在客户端某些选项可以完成逐行操作的任务，例如使用服务器端的tempdb表，或者使用一个关联子查询。

  不幸的是，这些方法并不通用，有时候你可能必须使用一个游标。如果你发现必须在你的应用程序中使用游标功能，那么以下这些建议或许对你有所帮助。

  SQL Server为你提供了几个不同类型的游标，每一个都有不同的性能特点。你应该选择可以实现你的目的同时开销又最小的游标类型。你可以选择的最高效游标是快速只进游标。

  在使用服务器端游标时，尽可能取最小的数据集。这包括只获取客户端立即需要的行和列。无论哪一种类型的服务器端游标，它越小，所使用的资源就越少，性能自然就越高。

  当你使用完一个游标后，不要简单的CLOSE它，你还必须对其进行DEALLOCATE操作，这样才会释放该游标所使用的SQL Server资源。如果你只是关闭它，锁虽然被释放，但是SQL Server资源却并未被释放，因此会降低服务器的性能。

  合理使用联合（Joins）

  对表进行联合（join）是造成性能问题的另一个主要做法，尤其是在联合的表超过了3个或者表非常大的情况下，更是如此。

  不幸的是，联合在关系数据库中是必不可少的。既然我们做不到不使用它，那么就看一下如何尽可能最优的使用它吧，请看以下技巧。

  如果你有两个或更多表需要频繁的进行联合，那么用于联合的列应该具有一个合适的索引。如果用于联合的列不简洁，那么可以考虑想数据表中增加代理键，以降低键值的大小，这样可以降低联合过程中的读I/O，从而提高整体性能。

  另外，你还需要了解更多的索引相关的信息。

  为使性能最大化，用于联合的列应该数据类型相同。而且尽可能为数值型数据类型而非字符类型。

  避免根据值不唯一的列进行表联合。如果用于联合的列在数值上不唯一，即使这些列上有索引，SQL Server优化器也将会执行表扫描然后进行联合。因此，为了获得更好的性能，要使用具有唯一索引的列来进行联合。

  如果你必须对四个以上的表定期进行联合，以获得所需的数据集，那么你可以考虑对这些表进行反规范化（denormalizing），这样联合表的数量会减少。一般情况下，通过从一个表向其它表中增加1-2列，就可以大大降低联合的需要。