对于SqlServer的优化来说，可能优化查询是很常见的事情。关于数据库的优化，本身也是一个涉及面比较的广的话题，本文只谈优化查询时如何看懂SqlServer查询计划。由于我对SqlServer的认识有限，如有错误，也恳请您在发现后及时批评指正。

首先，打开【SQL Server Management Studio】，输入一个查询语句看看SqlServer是如何显示查询计划的吧。
说明：本文所演示的数据库，是我写的一个演示程序专用的数据库

select v.OrderID, v.CustomerID, v.CustomerName, v.OrderDate, v.SumMoney, v.Finished from OrdersViewas v where v.OrderDate >= '2010-12-1' and v.OrderDate < '2011-12-1';

其中，OrdersView是一个视图，其定义如下：

SELECT dbo.Orders.OrderID, dbo.Orders.CustomerID, dbo.Orders.OrderDate, dbo.Orders.SumMoney,dbo.Orders.Finished, ISNULL(dbo.Customers.CustomerName, N'') AS CustomerName FROM dbo.Orders LEFT OUTER JOIN dbo.Customers ON dbo.Orders.CustomerID = dbo.Customers.CustomerID

对于前一句查询，SqlServer给出的查询计划如下（点击工具栏上的【显示估计的执行计划】按钮）：

从这个图，我们至少可以得到3个有用的信息：
1. 哪些执行步骤花费的成本比较高。显然，最右边的二个步骤的成本是比较高的。
2. 哪些执行步骤产生的数据量比较多。对于每个步骤所产生的数据量， SqlServer的执行计划是用【线条粗细】来表示的，因此也很容易地从分辨出来。
3. 每一步执行了什么样的动作。

对于一个比较慢的查询来说，我们通常首先要知道哪些步骤的成本比较高，进而，可以尝试一些改进的方法。一般来说，如果您不能通过：提高硬件性能或者调整OS,SqlServer的设置之类的方式来解决问题，那么剩下的可选方法通常也只有以下这些了：
1. 为【scan】这类操作增加相应字段的索引。
2. 有时重建索引或许也是有效的，具体情形请参考后文。
3. 调整语句结构，引导SqlServer采用其它的查询方案去执行。
4. 调整表结构（分表或者分区）。

下面再来说说一些很重要的理论知识，这些内容对于执行计划的理解是很有帮助的。

Sql Server 查找记录的方法

说到这里，不得不说SqlServer的索引了。SqlServer有二种索引：聚集索引和非聚集索引。二者的差别在于：【聚集索引】直接决定了记录的存放位置，或者说：根据聚集索引可以直接获取到记录。【非聚集索引】保存了二个信息：1.相应索引字段的值，2.记录对应聚集索引的位置（如果表没有聚集索引则保存记录指针）。因此，如果能通过【聚集索引】来查找记录，显然也是最快的。

Sql Server 会有以下方法来查找您需要的数据记录：
1. 【Table Scan】：遍历整个表，查找所匹配的记录行。这个操作将会一行一行的检查，当然，效率也是最差的。
2. 【Index Scan】：根据索引，从表中过滤出来一部分记录，再查找所匹配的记录行，显示比第一种方式的查找范围要小，因此比【Table Scan】要快。
3. 【Index Seek】：根据索引，定位（获取）记录的存放位置，然后取得记录，因此，比起前二种方式会更快。
4. 【Clustered Index Scan】：和【Table Scan】一样。注意：不要以为这里有个Index，就认为不一样了。其实它的意思是说：按聚集索引来逐行扫描每一行记录，因为记录就是按聚集索引来顺序存放的。而【Table Scan】只是说：要扫描的表没有聚集索引而已，因此这二个操作本质上也是一样的。
5. 【Clustered Index Seek】：直接根据聚集索引获取记录，最快！

所以，当发现某个查询比较慢时，可以首先检查哪些操作的成本比较高，再看看那些操作是查找记录时，是不是【Table Scan】或者【Clustered Index Scan】，如果确实和这二种操作类型有关，则要考虑增加索引来解决了。不过，增加索引后，也会影响数据表的修改动作，因为修改数据表时，要更新相应字段的索引。所以索引过多，也会影响性能。还有一种情况是不适合增加索引的：某个字段用0或1表示的状态。例如可能有绝大多数是1，那么此时加索引根本就没有意义。这时只能考虑为0或者1这二种情况分开来保存了，分表或者分区都是不错的选择。

如果不能通过增加索引和调整表来解决，那么可以试试调整语句结构，引导SqlServer采用其它的查询方案去执行。这种方法要求： 1.对语句所要完成的功能很清楚， 2.对要查询的数据表结构很清楚， 3.对相关的业务背景知识很清楚。如果能通过这种方法去解决，当然也是很好的解决方法了。不过，有时SqlServer比较智能，即使你调整语句结构，也不会影响它的执行计划。

如何比较二个同样功能的语句的性能好坏呢，我建议采用二种方法： 1. 直接把二个查询语句放在【SQL Server Management Studio】，然后去看它们的【执行计划】，SqlServer会以百分比的方式告诉你二个查询的【查询开销】。这种方法简单，通常也是可以参考的，不过，有时也会不准，具体原因请接着往下看(可能索引统计信息过旧)。
2. 根据真实的程序调用，写相应的测试代码去调用：这种方法就麻烦一些，但是它更能代表现实调用情况，得到的结果也是更具有参考价值的，因此也是值得的。

Sql Server Join 方式

在Sql Server中，我们每个join命令，都会在内部执行时，采用三种更具体的方式来运行：

1. 【Nested Loops join】，如果一个联接输入很小，而另一个联接输入很大而且已在其联接列上创建了索引，则索引 Nested Loops 连接是最快的联接操作，因为它们需要的 I/O 和比较都最少。

嵌套循环联接也称为“嵌套迭代”，它将一个联接输入用作外部输入表（显示为图形执行计划中的顶端输入），将另一个联接输入用作内部（底端）输入表。外部循环逐行处理外部输入表。内部循环会针对每个外部行执行，在内部输入表中搜索匹配行。可以用下面的伪码来理解：

foreach(row r1 in outer table) foreach(row r2 in inner table) if( r1, r2 符合匹配条件 ) output(r1, r2);

最简单的情况是，搜索时扫描整个表或索引；这称为“单纯嵌套循环联接”。如果搜索时使用索引，则称为“索引嵌套循环联接”。如果将索引生成为查询计划的一部分（并在查询完成后立即将索引破坏），则称为“临时索引嵌套循环联接”。查询优化器考虑了所有这些不同情况。

如果外部输入较小而内部输入较大且预先创建了索引，则嵌套循环联接尤其有效。在许多小事务中（如那些只影响较小的一组行的事务），索引嵌套循环联接优于合并联接和哈希联接。但在大型查询中，嵌套循环联接通常不是