原文 http://www.cnblogs.com/BoyceYang/archive/2013/06/15/3138142.html
阅读导航
在比较大的范围内找出能够大幅提高性能的区域，并且专注于分析这个区域，这是最有效的优化SQL Server性能的方式。否则，大量的时间和精力可能被浪费在不能提高很大性能的区域。在这里并没有讨论关于多用户并发所带来的性能问题。
能获得最大性能提高的区域一般是：逻辑数据库设计，索引设计，查询设计。然而，最大的性能问题经常由于缺乏这些方面研究的原因造成。如果性能是被列为一个需要关注的问题，聪明的做法是首先专注于这些方面， 因为性能的大幅提高经常是用相对较小的时间精力完成。
下面开始进入正题。
合理规范性的逻辑数据库设计可以产生最佳性能。大量的窄表是标准数据库的特性。少量的宽表是非标准数据的特性。高度标准数据库通常关联着复杂的表的 联合查询，这个可能损害数据库的性能。不管怎么样，SQL Server优化在快速查询、高效联接、可用有效索引方面是非常有效的，下面是规范化的好处：
- 如果是窄表，应该加快排序和创建索引
- 如果是宽表，最好使用聚集索引
- 索引往往是越窄的表，越应该精确
- 更好的利用段去控制表的物理空间
- 每个表的索引越少，对提高UPDATE操作的性能越有帮助
- 越少的NULLs列，越少的冗余数据，越能增加数据库的紧凑性
对于SQL Server，标准化将有助于提升而不是损害性能。随着标准化的提高，因此需要一定数量并且复杂的表连接来检索数据。只要标准化不会导致很多查询出现超过四个表的连接，就应进行标准化进程。
如果逻辑数据库设计已经固定，并且不可能进行整体重新设计，而且通过研究表明一个大表存在性能瓶颈，在这样的情况下，可以有选择性的对这个大表进行 标准化。如果过存储过程进行访问数据，那么架构的改变不会影响应用程序。如果不是这样，可以通过创建视图来隐藏这种改变，因为视图可以产生单个表的错觉。
不像很多非关系系统，不把关系索引考虑作为逻辑数据库设计的一部分。索引能被删除、添加和更新，除了影响性能以外，不会影响数据库架构或者应用程序 设计。实现良好的SQL Server性能，高效索引设计是非常重要的。由于这些原因，不要犹豫展示不同索引带来的性能改变吧。
大多数情况下，优化器将可靠地选择最高效的索引。所有的策略应该提供良好的索引优化的选择，相信这是正确的决定。这可以在多种情况下，减少分析时间并且能提供良好的性能。
接下来介绍索引。检查SQL查询的WHERE子句，因为这个是优化的主要焦点。在WHERE子句中列出的列都有可能成为索引的备选。假如有太多的语句需要检查，挑选有代表性的一组，或者仅仅是速度缓慢的那组。
最好使用窄索引。窄索引比混合索引和复合索引更加高效。窄索引每页行越多，索引级别应该越低，这样才能提高性能。SQL Server优化只是维护统计数据在复合索引最重要的列上。因此，如果复合索引的第一列可选择性很差，那么就不优化这个索引。
优化器可以快速、高效的分析成百上千的索引和表连接的可能性。有更多的窄索引提供给优化器，优化器就会有更多可能的选择，这对性能很有帮助。有较少的宽索引、复合索引提供给优化程器，优化器只有很少选择的可能性，这对性能会有影响。
索引数目太多性能可能会降低，因为涉及到更新这些索引的开销。然而，大量的面向更新操作需要更多的读操作，而不是写操作。假如，尝试新索引时提高了性能，那就不要犹豫，使用这个所以吧。
使用聚集索引。适当的使用聚集索引可以极大的提升性能。甚至聚集索引可以使UPDATE和DELETE操作提速，因为这些操作需要很多读操作。可能 每个表只有单一的聚集索引，因此，要灵活地利用这个索引。返回行数的查询或者涉及一个范围值的查询都是一个可能被聚集索引提高性能的候选。
例子：
1: SELECT * FROM PHONEBOOK
2:
3: WHERE NAME = ‘李雷’
4:
5: SELECT * FROM MEMERTABLE
6:
7: WHERE MEMBER_NO > 5000 AND MEMBER_NO < 6000
通过约束，上面提到的NAME和MEMBER_NO列，对于非聚集索引可能不是一个适合的候选。尽量在返回很少行数据的列上使用非聚集索引。
检查列数据的唯一性。这样将帮助决定，什么样的列作为聚集索引、非聚集索引、无需索引的备选。
查询语句检查数据的唯一性，例子：
1: SELECT COUNT (DISTINCT COLNAME) FROM TABLENAME
这个语句将返回一个列中不重复值的数量。在表中比较这个数量和总的行数。在一个一万行的表中，5000个不重复值的列对于非聚集索引可能是一个很好 的备选，20个不重复值的列可能最适合聚集索引，3个不重复值的列根本就不需要使用索引。这些仅仅是个例子，不是一成不变的规则。记住把索引建立在WHERE查询子句列出的每一个列上。
在索引选择时，查询语句返回行数也是一个重要的因素。优化器会考虑非聚集索引花费在每个返回行至少一页I/O的成本。以这样的速度，并不需要很长的时间就可以变得更高效的扫描整个表。理性对待结果集，要么限制结果集的大小，要么使用聚集索引定位巨大结果集。
某些查询语句本身是资源密集型。这关系到基本数据和索引在大多数RDBMSs（关系型数据库管理系统）的常见问题，而不是在特定SQL Server中。它 们并不低效，优化器将会尽可能实现高效的查询语句。然而，它们是资源密集型，SQL面向结果集的本性可能使它们出现低效。优化器的智能程度不可能消除这些 结构的固有资源成本。和更加简单的语句相比，他们内在的消耗更大。尽管SQL Server使用最优的访问计划，但还是会有限制的。
例如：
- 大型结果集
- IN和OR语句
- 高度非唯一WHERE子句
- !=（不等于）
- 某些列函数，比如SUM
- WHERE子句中的表达式或数据转换
- WHERE子句的局部变量
有些因素可能需要使用这些查询语句结构。如果优化器可以限制结果集，然后再应用资源密集型的查询，那么他们的影响将会减少。
例如:
1: 低效: SELECT SUM(SALARY) FROM TABLE
2:
3: 高效: SELECT SUM(SALARY) FROM TABLE WHERE ZIP='98052'
4:
5: 低效: SELECT * FROM TABLE WHERE LNAME=@VAR
6:
7: 高效: SELECT * FROM TABLE WHERE LNAME=@VAR AND ZIP='98052'
在第一个例子中，SUM操作使用索引并不能使其加速。每行都需要被读和求和。设想在ZIP列有一个索引，优化器将可能使用这个来初始限制结果集，然后再应用SUM函数。这可能会更快。
在第二个例子中，局部变量直到运行时才被赋值。然而优化器无法拖延到运行时才选择访问计划，必须在编译时进行选择。然而，在编译期间，当生成访问计 划时，@VAR的值还不能确定，因此不能使用输入的@VAR作为索引选择。可以使用AND子句对结果集进行限制。使用存储过程是一个可选技术，这样可以传 递参数，将参数赋值给存储过程中@VAR值。
大多数RDBMSs的大型结果集是很耗费性能。可以尝试不返回大型结果集到客户端作为最终数据选择。允许数据库后台执行预定函数，并限定结果集的大小，这种做法效率很高。
首先分离查询，或者分离比较慢的查询。当有少数SQL查询速度慢，经常表现为整个应用程序速度慢。对能够显示生成SQL的工具，使用这个工具的诊断或调试模式记录生成的SQL。使用嵌入式SQL工具会更加简单。分离速度慢的查询之前，先做一下下面的步骤：
- 单独运行疑似速度慢的语句，使用工具（例如ISQL、SAF）验证实际上是不是很慢。
- 使用SET STATISTICS IO ON，检查语句的I/O消耗和已选择的访问计划。优化器的目的是最小的I/O。记录逻辑I/O。以这个为基准测量改进成果
- 如果查询涉及视图或者存储过程，从中提取这些语句并单独运行。当尝试使用不同索引时，访问计划是可以改变。
- 有些表可以生成I/O作为触发器运行，这时要注意可能和这些表有关系的触发器和视图。
- 检查速度慢的语句表的索引。利用之前列出的技术检查是否有更好的索引，如果有必要就修改。
- 改变索引后重新运行查询，并观察I/O和访问计划的改变。
- 改进工作完成，运行主程序看看所有的性能是不是有所提升。
检查程序的I/O或CPU限制的行为。通常这个对确定查询语句是否在I/O或CPU临界状态很有用。我们要花费精力在提高真正的性能瓶颈上，例如， 如果一个查询是CPU临界状态，就算增加更多的内存给SQL Server也太可能有性能的提高，当然更多的内存还是能提高缓存命中率。下面的步骤是检查SQL Server的I/O和CPU临界状态：
- 使用OS/2 CPU监控程序。
- 当运行查询时，如果CPU使用率保持很高（>70%），这表明是CPU临界状态。
- 当运行查询时，如果CPU使用率保持很低（<50%），这表明也是CPU临界状态。
- 使用STATISTICS IO比较CPU利用率信息
SQL Server能够提高大型数据库的性能。要挖掘这个性能的潜力，需要有高效的数据库设计、索引和查询语句。这些区域是最可能成为捕获到重大性能提升的备选区域。尝试使用索引是一个很特别建议。通常，系统化的方法在分析性能问题上，不仅投入时间少，而且能产生巨大性能提升。
在此特别感谢@守望dreamstar对本篇文章的支持。
