在一个关系数据库中提高和优化查询方法。
很多人都将数据库看成神奇的圣人，即能够解决人们提出的各种问题。任何关系数据库都有一套解决查询的规则，而各种关系数据库查询的过程稍有所区别，但是基本的操作思想和过程是一致的。本文将为你介绍查询分析器解决查询的方法和过程。
查询优化的目标
在查看分析器查询的步骤之前，理解查询优化目标相当重要。显然，查询操作的其中一个目标是尽可能地减少使用资源。从数据库的角度看，这就意味着尽可能地减少I/O操作的次数。
在对I/O操作的判断上，查询分析器经常做出错误的结果。而I/O操作次数必须满足磁盘的读取容量。这样从磁盘I/O读取的角度看，必须做出合理的选择条件。
索引
基于表格的索引是关系数据库用于解决查询的重要技术，也是数据库同时预先将数据分类导入到多表格的方式。通过索引中的字段和实际数据存放的指针可以完成以上的过程。
除了集簇索引（Clustered Index），每一索引的使用都以磁盘容量作为代价。集簇索引是真正意义上与磁盘读取和磁盘容量代价无关的方法，因为集簇索引是真正按照顺序将数据存储到表格。
当使用一个索引，数据库引擎必须执行两个数据读取，这两个数据读取是数据库记录所必需的。第一个数据被读取到实际数据指针的索引。第二个数据被读入到指针指定的位置。此时必须通过数据库服务器来查询，所以考虑系统资源消耗是有必要的。这也是查询分析器不使用索引的主要原因。在后面的部分中，即Covering Indices，你将学会不使用这两种读取的方法——然而，在很多时候使用索引即意味着每一记录可以完成两次读取。
统计页
统计页（Statistics page）是SQL Server用于决定是否使用索引时必需的信息。每一索引都有一个信息表，以将表格所有数据的索引关键值分布告诉查询优化器。统计页可用于大致估计从一个查询返回的行数。
查询分析器必须知道返回的行数，由此确定是否值得使用索引方式。如果查询优化器从索引统计页中得知将返回几行，它就会选择使用索引；如果从统计页中得知将返回大数量的行数，索引查询优化器将有可能使用一个表扫描来解决查询。
字段顺序
当使用到索引时，字段顺序(Field order)代表众多字段的顺序。当判断是否使用索引时，服务器必须从第一字段到最后字段扫描。任何与查询无关的字段都将该索引清除掉。
当进行索引安排时，你应该将最经常使用到的查询排列在索引最顶端，不属于查询范围的字段可以使查询优化器忽略整个索引。
使用WHERE语句
