SQL Server 查询分析器的执行计划中的扫描方式，举例理解

student表,id，name，address

id上建立聚集索引，Name建索引，address无索引。
1. 【Table Scan】：遍历整个表，查找所有匹配的记录行。这个操作将会一行一行的检查，当然，效率也是最差的。

以无索引字段为条件，按存放顺序一个个查，同4
where address='123'

2. 【Index Scan】：根据索引，从表中过滤出来一部分记录，再查找所有匹配的记录行，显然比第一种方式的查找范围要小，因此比【Table Scan】要快。

多重条件?有索引列，无索引列，先从索引列找出范围，再遍历这个范围匹配无索引列。
where name='cui' and address='123'

3. 【Index Seek】：根据索引，定位（获取）记录的存放位置，然后取得记录，因此，比起前二种方式会更快。
有索引的单独查询。通过索引找到位置，再找数据。

where name='cui'

4. 【Clustered Index Scan】：和【Table Scan】一样。注意：不要以为这里有个Index，就认为不一样了。其实它的意思是说：按聚集索引来逐行扫描每一行记录，因为记录就是按聚集索引来顺序存放的。而【Table Scan】只是说：要扫描的表没有聚集索引而已，因此这二个操作本质上也是一样的。

5. 【Clustered Index Seek】：直接根据聚集索引获取记录，最快！

where id=1; 聚集索引存的就是位置。比3少一步

联接方式：

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

外部传入小表（无索引），再在内部的大表查询，主要开销在查内部的大表上，影响速度主要是大表，大表有索引当然更快。

在许多小事务中（如那些只影响较小的一组行的事务），索引嵌套循环联接优于合并联接和哈希联接。但在大型查询中，嵌套循环联接通常不是最佳选择。

2. 【Merge Join】，如果两个联接输入并不小但已在二者联接列上排序（例如，如果它们是通过扫描已排序的索引获得的），则合并联接是最快的联接操作。如果两个联接输入都很大，而且这两个输入的大小差不多，则预先排序的合并联接提供的性能与哈希联接相近。但是，如果这两个输入的大小相差很大，则哈希联接操作通常快得多。

A.a=B.b
A表的索引查出数据，B表的索引查出数据

合并联接本身的速度很快，但如果需要排序操作，选择合并联接就会非常费时。然而，如果数据量很大且能够从现有 B 树索引中获得预排序的所需数据，则合并联接通常是最快的可用联接算法。

3. 【Hash Join】，哈希联接可以有效处理未排序的大型非索引输入。它们对复杂查询的中间结果很有用，因为： 1. 中间结果未经索引（除非已经显式保存到磁盘上然后创建索引），而且通常不为查询计划中的下一个操作进行适当的排序。 2. 查询优化器只估计中间结果的大小。由于对于复杂查询，估计可能有很大的误差，因此如果中间结果比预期的大得多，则处理中间结果的算法不仅必须有效而且必须适度弱化。

未排序无索引。