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

时间:2023-01-29 03:38:21


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. 查询优化器只估计中间结果的大小。由于对于复杂查询,估计可能有很大的误差,因此如果中间结果比预期的大得多,则处理中间结果的算法不仅必须有效而且必须适度弱化。

 未排序无索引。