看懂sql执行计划
sql执行计划
sql执行计划SQL执行计划。
SQL执行计划是指数据库系统在执行SQL语句时所生成的一种执行策略，它描述了数据库系统是如何获取数据的，以及使用了哪些索引、表连接方式等信息。
通过分析SQL执行计划，可以帮助我们优化SQL语句，提高查询性能。
SQL执行计划的生成过程是由数据库系统的查询优化器完成的。
当我们执行一个SQL语句时，数据库系统会首先对该SQL语句进行语法分析和语义分析，然后将其转换成逻辑查询计划，再经过一系列的优化规则和成本估算，最终生成物理查询计划，也就是SQL执行计划。
在SQL执行计划中，最常见的信息包括表的访问方式（全表扫描、索引扫描等）、表之间的连接方式（嵌套循环连接、哈希连接、排序合并连接等）、使用的索引信息、过滤条件等。
通过分析这些信息，我们可以了解数据库系统是如何执行SQL语句的，从而发现潜在的性能瓶颈，进行优化。
SQL执行计划的生成和分析工具有很多种，比如Oracle的Explain Plan、SQL Server的Execution Plan、MySQL的Explain 等。
这些工具可以帮助我们查看SQL执行计划，分析SQL语句的性能，找出潜在的优化点。
在实际工作中，我们可以通过以下几种方式来分析SQL执行计划，以优化SQL语句的性能：1. 使用数据库系统自带的工具来查看执行计划。
不同的数据库系统有不同的执行计划查看工具，比如Oracle的SQL Developer、SQL Server的Management Studio等。
通过这些工具，我们可以直观地查看SQL执行计划，了解SQL语句的执行情况。
2. 使用Explain语句来查看执行计划。
大部分数据库系统都支持Explain语句，通过在SQL语句前加上Explain关键字，可以查看该SQL语句的执行计划。
这种方式适合于在命令行或者脚本中进行SQL执行计划的分析。
3. 使用第三方的SQL优化工具。
除了数据库系统自带的工具外，还有很多第三方的SQL优化工具可以帮助我们分析SQL执行计划，比如TOAD、SQL Tuning Advisor等。
sql 执行计划
sql 执行计划SQL执行计划是指在执行SQL语句时，数据库系统为了找到最优的执行方式而生成的执行计划。
通过执行计划，我们可以了解数据库系统是如何执行我们的SQL语句的，从而可以对SQL语句进行优化，提高执行效率。
本文将介绍SQL执行计划的生成过程、执行计划的内容以及如何通过执行计划进行SQL语句的优化。
SQL执行计划的生成过程。
在数据库系统中，当我们执行一条SQL语句时，数据库系统会首先对这条SQL语句进行解析，然后生成执行计划。
执行计划的生成过程可以分为以下几个步骤：1. 语法解析，数据库系统首先对SQL语句进行语法解析，检查SQL语句是否符合语法规范，如果语法错误则会返回错误信息，如果语法正确则进行下一步处理。
2. 语义解析，在语法解析通过之后，数据库系统会对SQL语句进行语义解析，检查SQL语句中的表、字段等是否存在，如果不存在则返回错误信息，如果存在则进行下一步处理。
3. 查询优化，在语义解析通过之后，数据库系统会对SQL语句进行查询优化，生成多个可能的执行计划，然后选择最优的执行计划。
4. 执行计划生成，最后，数据库系统根据选择的执行计划生成最终的执行计划，并将其存储在执行计划缓存中，以便执行时使用。
执行计划的内容。
执行计划通常包括以下内容：1. 执行顺序，执行计划中会显示SQL语句中各个操作的执行顺序，如先执行哪个表的扫描操作，再执行哪个表的连接操作等。
2. 访问方法，执行计划中会显示数据库系统选择的访问方法，如全表扫描、索引扫描、排序等。
3. 访问顺序，执行计划中会显示数据库系统选择的访问顺序，如表的连接顺序、索引的使用顺序等。
4. 访问类型，执行计划中会显示数据库系统选择的访问类型，如等值查询、范围查询、排序等。
通过执行计划进行SQL语句的优化。
通过执行计划，我们可以对SQL语句进行优化，提高执行效率。
具体来说，可以从以下几个方面进行优化：1. 减少全表扫描，全表扫描是数据库系统中的一种低效的查询方式，可以通过创建索引或者优化查询条件来减少全表扫描的次数。
sql执行计划怎么看
sql执行计划怎么看对于理解和分析SQL查询的性能，SQL执行计划是一个非常重要的工具。
SQL执行计划提供了关于查询如何执行的详细信息，包括优化器选择使用的算法、访问方法和数据流程等。
通过查看执行计划，可以确定查询是否具有高效的性能，以及是否需要对查询或数据库结构进行优化。
要查看SQL执行计划，可以使用DBMS的命令行界面或图形化界面工具。
下面是一些常见的方法来获取SQL执行计划的步骤。
1. 使用命令行工具：a. 启动命令行界面，例如SQL Server Management Studio (SSMS) 或 MySQL的命令行客户端。
b. 连接到数据库，并选择要执行查询的数据库。
c. 输入要执行的SQL查询，并使用"EXPLAIN"关键字（对于某些数据库，可能使用"EXPLAIN PLAN"）在查询之前。
d. 执行查询，数据库服务器将返回查询的执行计划。
2. 使用图形化界面工具：a. 打开SQL查询工具，例如SSMS、Navicat、Toad等。
b. 连接到数据库，并选择要执行查询的数据库。
c. 输入要执行的SQL查询。
d. 在工具的菜单栏或工具栏中找到和执行计划相关的功能，例如"Show Execution Plan"或类似的选项。
e. 执行查询，工具将显示查询的执行计划。
了解如何获取SQL执行计划后，下面是执行计划的一些常见元素，以及如何解读它们：1. 查询计划：- 选择了哪种类型的查询计划，例如表扫描、索引扫描、索引查找等。
- 查询操作的顺序和组织方式。
2. 数据访问方法：- 使用哪种数据访问方法，例如全表扫描、索引扫描、索引查找等。
- 访问方法的成本和效率。
3. 连接方法：- 如果查询涉及多个表，连接的顺序和方法是如何选择的。
- 连接方法的成本和效率。
4. 过滤和条件：- 查询中使用的过滤条件，以及它们是如何被执行的。
- 过滤条件的成本和效率。
SQL执行计划详解explain
SQL执⾏计划详解explain1.使⽤explain语句去查看分析结果如explain select * from test1 where id=1;会出现：id selecttype table type possible_keys key key_len ref rows extra各列。
其中，type=const表⽰通过索引⼀次就找到了；key=primary的话，表⽰使⽤了主键；type=all,表⽰为全表扫描；key=null表⽰没⽤到索引。
type=ref，因为这时认为是多个匹配⾏，在联合查询中，⼀般为REF。
2.MYSQL中的组合索引假设表有id,key1,key2,key3,把三者形成⼀个组合索引，则如：复制代码代码如下:1.where key1=....2.where key1=1 and key2=23.where key1=3 and key2=3 and key3=2根据最左前缀原则，这些都是可以使⽤索引的，如from test where key1=1 order by key3，⽤explain分析的话，只⽤到了normal_key索引，但只对where⼦句起作⽤，⽽后⾯的order by需要排序。
3.使⽤慢查询分析（实⽤）在my.ini中：long_query_time=1log-slow-queries=d:\mysql5\logs\mysqlslow.log把超过1秒的记录在慢查询⽇志中可以⽤mysqlsla来分析之。
也可以在mysqlreport中，有如DMS分别分析了select ,update,insert,delete,replace等所占的百分⽐4.MYISAM和INNODB的锁定myisam中，注意是表锁来的，⽐如在多个UPDATE操作后，再SELECT时，会发现SELECT操作被锁定了，必须等所有UPDATE操作完毕后，再能SELECTinnodb的话则不同了，⽤的是⾏锁，不存在上⾯问题。
sql执行计划
sql执行计划SQL执行计划。
SQL执行计划是数据库系统中非常重要的概念，它用于描述数据库系统在执行SQL语句时所采取的具体执行步骤和方法。
通过分析SQL执行计划，可以帮助我们优化SQL语句，提高数据库查询性能。
本文将介绍SQL执行计划的基本概念、生成方式和优化方法。
SQL执行计划的基本概念。
SQL执行计划是数据库系统根据SQL语句生成的一种执行策略，它描述了数据库系统在执行SQL语句时所采取的具体执行步骤和方法。
SQL执行计划通常以树状结构的形式呈现，其中包括了SQL语句的执行顺序、使用的索引、表的访问方式、连接方式等信息。
通过分析SQL执行计划，可以了解数据库系统是如何执行SQL语句的，从而找出可能存在的性能瓶颈并进行优化。
SQL执行计划的生成方式。
数据库系统生成SQL执行计划的方式通常有两种，静态执行计划和动态执行计划。
静态执行计划是在SQL语句编译阶段生成并缓存的执行计划，它在SQL语句执行时直接使用，适用于执行频率较高的SQL语句。
而动态执行计划是在SQL语句执行时动态生成的执行计划，适用于执行频率较低的SQL语句。
优化SQL执行计划的方法。
为了提高数据库查询性能，我们可以通过优化SQL执行计划来实现。
以下是一些常用的优化方法：1. 使用合适的索引，索引是数据库系统提高查询性能的重要手段，通过为查询字段创建合适的索引，可以加快查询速度。
在分析SQL执行计划时，可以查看数据库系统是否使用了合适的索引，如果没有，就需要考虑创建新的索引或修改SQL语句。
2. 避免全表扫描，全表扫描是指数据库系统对整张表进行遍历查询，通常会消耗大量的系统资源。
在分析SQL执行计划时，可以查看是否存在全表扫描的情况，如果有，就需要考虑优化SQL语句或创建合适的索引。
3. 使用合适的连接方式，在执行涉及多张表的SQL语句时，数据库系统会根据连接条件选择合适的连接方式，如嵌套循环连接、哈希连接、排序合并连接等。
在分析SQL执行计划时，可以查看数据库系统选择的连接方式是否合适，如果不合适，就需要考虑优化连接条件或修改SQL语句。
通过分析SQL语句的执行计划优化SQL
通过分析SQL语句的执行计划优化SQL
1.确定问题SQL：首先要确定哪个SQL语句是需要优化的，可以根据
数据库性能监控或慢查询日志等方式来定位。
2.分析执行计划：执行计划是数据库查询优化的关键，通过分析执行
计划可以了解SQL查询使用的索引、连接方式、数据访问路径等重要信息。
3.选择合适的索引：根据执行计划中的信息，考虑是否需要添加或修
改索引。
适当的索引可以大大提高查询性能，但是过多或不合适的索引也
会拖慢性能。
4.避免全表扫描：全表扫描是非常低效的操作，可以通过添加合适的
索引来避免全表扫描，或者优化查询条件使得数据库可以利用索引进行查询。
5.利用查询缓存：数据库中可能存在查询缓存，可以将频繁查询的SQL语句缓存起来，提高查询性能。
6.合理使用子查询：子查询可以增加数据访问的复杂性，需要谨慎使用。
可以重写SQL语句，将子查询转换为连接查询或者使用临时表等方式
避免子查询的使用。
7.调整SQL语句的顺序：在复杂的SQL语句中，表的连接顺序会影响
查询性能。
可以通过调整表的连接顺序，使得执行计划更为高效。
8.数据库优化：除了优化SQL语句，还可以从数据库本身进行优化，
比如调整数据库的参数配置，增加硬件资源等方式来提高数据库性能。
总之，通过分析SQL语句的执行计划，结合合适的索引和优化技巧，
可以大大提高SQL查询的性能。
看懂MSSQL执行计划，分析SQL语句执行情况
看懂MSSQL执⾏计划，分析SQL语句执⾏情况打开SQL执⾏计划窗⼝
执⾏计划的图表是从右向左看的
SQL Server有⼏种⽅式查找数据记录
[Table Scan] 表扫描（最慢），对表记录逐⾏进⾏检查
[Clustered Index Scan] 聚集索引扫描（较慢），按聚集索引对记录逐⾏进⾏检查
[Index Scan] 索引扫描（普通），根据索引滤出部分数据在进⾏逐⾏检查
[Index Seek] 索引查找（较快），根据索引定位记录所在位置再取出记录
[Clustered Index Seek] 聚集索引查找（最快），直接根据聚集索引获取记录
（如果有些sql执⾏很慢可以看⼀下执⾏计划是否包含太多“扫描”操作，如果有可以考虑为这些字段建⽴索引，建⽴索引切记不要再经常有更新操作的字段上建⽴，每次更新都会导致重建索引的操作，也会影响性能，0或1这种标识状态的字段因为⼤部分数据都是⼀样的建⽴索引也没有什么作⽤）
（索引就两种，1是聚集索引，2个⾮聚集索引，聚集索引每张表只能有⼀个，⾮聚集索引每张表可以有多个，主键Id就是典型的聚集索引，聚集索引是顺序排列的类似于字典查找拼⾳a、b、c……和字典⽂字内容顺序是相同的，⾮聚集索引与内容是⾮顺序排列的，类似字典偏旁查找时，同⼀个偏旁‘马’的汉字可能⼀个在第10页⼀个在第100页）。
sql的执行计划
sql的执行计划SQL的执行计划。
SQL的执行计划是数据库系统中非常重要的概念，它决定了SQL查询语句在数据库中的执行方式和效率。
在进行SQL查询优化时，了解和分析SQL的执行计划是至关重要的。
本文将介绍SQL的执行计划是什么，如何获取执行计划，以及如何分析执行计划来进行SQL查询优化。
执行计划是指数据库系统在执行SQL查询语句时生成的一种执行策略。
它告诉我们数据库系统将如何获取数据，以及在获取数据的过程中使用了哪些索引、连接方式、排序方式等。
通过分析执行计划，我们可以了解到SQL查询语句的执行效率，从而进行优化。
获取SQL执行计划的方法有多种，其中最常用的方法是使用数据库系统提供的explain命令或者类似的工具。
通过explain命令，我们可以获取到数据库系统生成的执行计划，并进行分析。
在MySQL中，可以使用"explain + SQL查询语句"来获取执行计划；在Oracle中，可以使用"explain plan for + SQL查询语句"来获取执行计划。
一旦获取了执行计划，我们就可以开始分析了。
执行计划通常以树状结构的方式展现，其中包括了访问方法、访问类型、索引使用情况、行数估算等信息。
通过分析执行计划，我们可以找出SQL 查询语句的瓶颈所在，从而进行优化。
比如，如果执行计划中出现了全表扫描，那么可能需要考虑增加索引来提高查询效率；如果执行计划中出现了排序操作，那么可能需要考虑优化排序算法等。
在分析执行计划时，需要注意以下几点，首先，要关注访问方法和访问类型，这两个信息可以告诉我们数据库系统是如何获取数据的；其次，要注意索引使用情况，索引的使用情况直接影响了查询的效率；最后，要注意行数估算，行数估算的准确性对于执行计划的分析至关重要。
除了使用explain命令外，还可以通过一些可视化的工具来获取和分析执行计划。
这些工具可以以图形化的方式展现执行计划，更直观地帮助我们理解和分析执行计划。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
对于SqlServer的优化来说，可能优化查询是很常见的事情。
关于数据库的优化，本身也是一个涉及面比较的广的话题，首先，打开【SQL Server Management Studio】，输入一个查询语句看看SqlServer是如何显示查询计划的吧。
其中，OrdersView是一个视图，其定义如下：对于前一句查询，SqlServer给出的查询计划如下（点击工具栏上的【显示估计的执行计划】按钮）：从这个图，我们至少可以得到3个有用的信息：1. 哪些执行步骤花费的成本比较高。
显然，最右边的二个步骤的成本是比较高的。
2. 哪些执行步骤产生的数据量比较多。
对于每个步骤所产生的数据量， SqlServer的执行计划是用【线条粗细】来表示的，因此也很容易地从分辨出来。
3. 每一步执行了什么样的动作。
对于一个比较慢的查询来说，我们通常首先要知道哪些步骤的成本比较高，进而，可以尝试一些改进的方法。
一般来说，如果您不能通过：提高硬件性能或者调整OS,SqlServer的设置之类的方式来解决问题，那么剩下的可选方法通常也只有以下这些了：1. 为【scan】这类操作增加相应字段的索引。
2. 有时重建索引或许也是有效的，具体情形请参考后文。
3. 调整语句结构，引导SqlServer采用其它的查询方案去执行。
4. 调整表结构（分表或者分区）。
下面再来说说一些很重要的理论知识，这些内容对于执行计划的理解是很有帮助的。
说到这里，不得不说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命令，都会在内部执行时，采用三种更具体的方式来运行：1. 【Nested Loops join】，如果一个联接输入很小，而另一个联接输入很大而且已在其联接列上创建了索引，则索引 Nested Loops 连接是最快的联接操作，因为它们需要的 I/O 和比较都最少。
嵌套循环联接也称为“嵌套迭代”，它将一个联接输入用作外部输入表（显示为图形执行计划中的顶端输入），将另一个联接输入用作内部（底端）输入表。
外部循环逐行处理外部输入表。
内部循环会针对每个外部行执行，在内部输入表中搜索匹配行。
可以用下面的伪码来理解：最简单的情况是，搜索时扫描整个表或索引；这称为“单纯嵌套循环联接”。
如果搜索时使用索引，则称为“索引嵌套循环联接”。
如果将索引生成为查询计划的一部分（并在查询完成后立即将索引破坏），则称为“临时索引嵌套循环联接”。
查询优化器考虑了所有这些不同情况。
如果外部输入较小而内部输入较大且预先创建了索引，则嵌套循环联接尤其有效。
在许多小事务中（如那些只影响较小的一组行的事务），索引嵌套循环联接优于合并联接和哈希联接。
但在大型查询中，嵌套循环联接通常不是最佳选择。
2. 【Merge Join】，如果两个联接输入并不小但已在二者联接列上排序（例如，如果它们是通过扫描已排序的索引获得的），则合并联接是最快的联接操作。
如果两个联接输入都很大，而且这两个输入的大小差不多，则预先排序的合并联接提供的性能与哈希联接相近。
但是，如果这两个输入的大小相差很大，则哈希联接操作通常快得多。
合并联接要求两个输入都在合并列上排序，而合并列由联接谓词的等效 (ON) 子句定义。
通常，查询优化器扫描索引（如果在适当的一组列上存在索引），或在合并联接的下面放一个排序运算符。
在极少数情况下，虽然可能有多个等效子句，但只用其中一些可用的等效子句获得合并列。
由于每个输入都已排序，因此 Merge Join 运算符将从每个输入获取一行并将其进行比较。
例如，对于内联接操作，如果行相等则返回。
如果行不相等，则废弃值较小的行并从该输入获得另一行。
这一过程将重复进行，直到处理完所有的行为止。
合并联接操作可以是常规操作，也可以是多对多操作。
多对多合并联接使用临时表存储行（会影响效率）。
如果每个输入中有重复值，则在处理其中一个输入中的每个重复项时，另一个输入必须重绕到重复项的开始位置。
可以创建唯一索引告诉SqlServer不会有重复值。
如果存在驻留谓词，则所有满足合并谓词的行都将对该驻留谓词取值，而只返回那些满足该驻留谓词的行。
合并联接本身的速度很快，但如果需要排序操作，选择合并联接就会非常费时。
然而，如果数据量很大且能够从现有 B 树索引中获得预排序的所需数据，则合并联接通常是最快的可用联接算法。
3. 【Hash Join】，哈希联接可以有效处理未排序的大型非索引输入。
它们对复杂查询的中间结果很有用，因为：1. 中间结果未经索引（除非已经显式保存到磁盘上然后创建索引），而且通常不为查询计划中的下一个操作进行适当的排序。
2. 查询优化器只估计中间结果的大小。
由于对于复杂查询，估计可能有很大的误差，因此如果中间结果比预期的大得多，则处理中间结果的算法不仅必须有效而且必须适度弱化。
哈希联接可以减少使用非规范化。
非规范化一般通过减少联接操作获得更好的性能，尽管这样做有冗余之险（如不一致的更新）。
哈希联接则减少使用非规范化的需要。
哈希联接使垂直分区（用单独的文件或索引代表单个表中的几组列）得以成为物理数据库设计的可行选项。
哈希联接有两种输入：生成输入和探测输入。
查询优化器指派这些角色，使两个输入中较小的那个作为生成输入。
哈希联接用于多种设置匹配操作：内部联接；左外部联接、右外部联接和完全外部联接；左半联接和右半联接；交集；联合和差异。
此外，哈希联接的某种变形可以进行重复删除和分组，例如SUM(salary) GROUP BY department。
这些修改对生成和探测角色只使用一个输入。
哈希联接又分为3个类型：内存中的哈希联接、Grace 哈希联接和递归哈希联接。
内存中的哈希联接：哈希联接先扫描或计算整个生成输入，然后在内存中生成哈希表。
根据计算得出的哈希键的哈希值，将每行插入哈希存储桶。
如果整个生成输入小于可用内存，则可以将所有行都插入哈希表中。
生成阶段之后是探测阶段。
一次一行地对整个探测输入进行扫描或计算，并为每个探测行计算哈希键的值，扫描相应的哈希存储桶并生成匹配项。
Grace 哈希联接：如果生成输入大于内存，哈希联接将分为几步进行。
这称为“Grace 哈希联接”。
每一步都分为生成阶段和探测阶段。
首先，消耗整个生成和探测输入并将其分区（使用哈希键上的哈希函数）为多个文件。
对哈希键使用哈希函数可以保证任意两个联接记录一定位于相同的文件对中。
因此，联接两个大输入的任务简化为相同任务的多个较小的实例。
然后将哈希联接应用于每对分区文件。
递归哈希联接：如果生成输入非常大，以至于标准外部合并的输入需要多个合并级别，则需要多个分区步骤和多个分区级别。
如果只有某些分区较大，则只需对那些分区使用附加的分区步骤。
为了使所有分区步骤尽可能快，将使用大的异步 I/O 操作以便单个线程就能使多个磁盘驱动器繁忙工作。
在优化过程中不能始终确定使用哪种哈希联接。
因此，SQL Server 开始时使用内存中的哈希联接，然后根据生成输入的大小逐渐转换到 Grace 哈希联接和递归哈希联接。
如果优化器错误地预计两个输入中哪个较小并由此确定哪个作为生成输入，生成角色和探测角色将动态反转。
哈希联接确保使用较小的溢出文件作为生成输入。
这一技术称为“角色反转”。
至少一个文件溢出到磁盘后，哈希联接中才会发生角色反转。
说明：您也可以显式的指定联接方式，SqlServer会尽量尊重您的选择。
比如你可以这样写：inner loop join, left outer merge join, inner hash join但是，我还是建议您不要这样做，因为SqlServer的选择基本上都是正确的，不信您可以试一下。