很多数据库系统性能不理想是因为系统没有经过整体优化，存在大量性能低下的SQL 语句。这类SQL语句性能不好的首要原因是缺乏高效的索引。没有索引除了导致语句本身运行速度慢外，更是导致大量的磁盘读写操作，使得整个系统性能都受之影响而变差。
解决这类系统的首要办法是优化这些没有索引或索引不够好的SQL语句。
创建索引的关键##
优化SQL语句的关键是尽可能减少语句的logical reads。这里说的logical reads是指语句执行时需要访问的单位为8K的数据页总数。logical reads 越少，其需要的内存和CPU时间也就越少，语句执行速度就越快。不言而喻，索引的最大好处是它可以极大减少SQL语句的logical reads数目，从而极大减少语句的执行时间。
创建索引的关键是索引要能够大大减少语句的logical reads。一个索引好不好，主要看它减少的logical reads多不多。
运行set statistics io命令可以得到SQL语句的logical reads信息。
set statistics io on
select au_id,au_lname ,au_fname
from pubs..authors where au_lname ='Green'
set statistics io on
如果Logical reads很大，而返回的行数很少，也即两者相差较大，那么往往意味者语句需要优化。Logical reads中包含该语句从内存数据缓冲区中访问的页数和从物理磁盘读取的页数。而physical reads表示那些没有驻留在内存缓冲区中需要从磁盘读取的数据页。Read-ahead reads是SQL Server为了提高性能而产生的预读。预读可能会多读取一些数据。
优化的时候我们主要关注Logical Reads就可以了。
注意如果physical Reads或Read-ahead reads很大，那么往往意味着语句的执行时间（duration）里面会有一部分耗费在等待物理磁盘IO上。
单字段索引，组合索引和覆盖索引##
单字段索引是指只有一个字段的索引，而组合索引指有多个字段构成的索引。
- 对出现在where子句中的字段加索引
set statistics profile on
set statistics io on
go
select .... from tb where ...
go
set statistics profile off
set statistics io off
set statistics profile命令将输出语句的执行计划。也许你会问，为什么不用SET SHOWPLAN_ALL呢？使用SET SHOWPLAN_ALL也是可以的。不过set statistics profile输出的是SQL 语句的运行时候真正使用的执行计划，而SET SHOWPLAN_ALL输出的是预计（Estimate）的执行计划。使用SET SHOWPLAN_ALL是后面的语句并不会真正运行。
- 组合索引
如果where语句中有多个字段，那么可以考虑创建组合索引。组合索引中字段的顺序是非常重要的，越是唯一的字段越是要靠前。另外，无论是组合索引还是单个列的索引，尽量不要选择那些唯一性很低的字段。
比如说，在只有两个值0和1的字段上建立索引没有多大意义。所以如果对单字段进行索引，建议使用set statistics profile来验证索引确实被充分使用。logical reads越少的索引越好。
- 覆盖索引
覆盖索引能够使得语句不需要访问表仅仅访问索引就能够得到所有需要的数据。因为聚集索引叶子节点就是数据所以无所谓覆盖与否，所以覆盖索引主要是针对非聚集索引而言。
问题1，是否值得在identity字段上建立聚集索引。
答案取决于identity字段如何在语句中使用。如果你经常根据该字段搜索返回很少的行，那么在其上建立索引是值得的。反之如果identity字段根本很少在语句中使用，那么就不应该对其建立任何索引。
问题2，一个表应该建立多少索引合适。
如果表的80％以上的语句都是读操作，那么索引可以多些。但是不要太多。特别是不要对那些更新频繁的表其建立很多的索引。很少表有超过5个以上的索引。过多的索引不但增加其占用的磁盘空间，也增加了SQL Server 维护索引的开销。
问题3：为什么SQL Server在执行计划中没有使用你认为应该使用的索引？原因是多样的。
一种原因是该语句返回的结果超过了表的20％数据，使得SQL Server 认为scan比seek更有效。另一种原因可能是表字段的statistics过期了，不能准确反映数据的分布情况。你可以使用命令UPDATE STATISTICS tablename with FULLSCAN来更新它。
只有同步的准确的statistics才能保证SQL Server 产生正确的执行计划。过时的老的statistics常会导致SQL Server生成不够优化的甚至愚蠢的执行计划。
所以如果你的表频繁更新，而你又觉得和之相关的SQL语句运行缓慢，不妨试试UPDATE STATISTIC with FULLSCAN 语句。
问题4、什么使用聚集索引，什么时候使用非聚集索引
在SQL Server 中索引有聚集索引和非聚集索引两种。它们的主要差别是前者的索引叶子就是数据本身，而后者的叶子节点包含的是指向数据的书签（即数据行号或聚集索引的key）。
对一个表而言聚集索引只能有一个，而非聚集索引可以有多个。
聚集索引不适用于：
频繁更改的列：
这将导致整行移动（因为 SQL Server 必须按物理顺序保留行中的数据值）。这一点要特别注意，因为在大数据量事务处理系统中数据是易失的。
宽键
来自聚集索引的键值由所有非聚集索引作为查找键使用，因此存储在每个非聚集索引的叶条目内。
总结##
如何使一个性能缓慢的系统运行更快更高效，不但需要整体分析数据库系统，找出系统的性能瓶颈，更需要优化数据库系统发出的SQL 语句。
一旦找出关键的SQL语句并加与优化，性能问题就会迎刃而解。
