可以说，Join的顺序是查询优化过程中最复杂的问题（当然，这里的复杂性在于，对于查询优化器来说，我们不会多次看到和关注这种复杂性），因为它涉及计算每个替代Join的顺序的成本。可以说，联接的顺序和数目与生成候选的执行计划的数量直接相关，从而极大地影响查询优化器的优化过程。
    
     当谈到Join时，我们都熟悉组合来自两个表的公共信息的想法。Join的操作只能一次在两个表之间进行，所以如果一个查询想要N个Join表，那么它就需要（N-1）次Join操作，即首先要第一个表和第二个ta可以加入，然后连接的结果与第三表连接，等等。
    
     在这一部分中，我们将讨论连接的顺序。我相信在阅读之后，我们会给大家一个新的理解。至于Join算法，因为它涉及执行引擎的部分，我们将在下文中讨论它。
    
     如前所述，表中的连接顺序决定查询的性能和成本。对于现有查询，可以生成许多候选执行计划。尽管这些执行计划返回相同的结果，但是由不同的Join生成的执行计划的成本确实有很大的不同。
    
     由于联接操作具有交换规律和组合规律的特征，即使一个简单的查询也会由于联接顺序的不同而生成许多不同的执行计划，并且执行计划的数量会随着联接表数量的增加而呈指数增长。查询优化器的任务是在这些众多的执行计划中选择一个更好的Join-order执行计划。
    
     首先来看一下交换法则。这个数学概念，因为SQL Server是关系数据，它的理论基础是关系集理论，而现在数学是基于集合的，所以SQL Server的设计，也引入了很多数学理论。加入B等于B加入A。
    
     交换法还定义了首先访问哪个表。例如，在Nest Loops Join操作中，被访问的第一个表称为外部表，而第二个表称为内部表。在Hash Join中，被访问的第一个表称为内部构建表，而第二个表是探测输入。表或建筑表的内部或探头输入有巨大的影响性能。
    
     Join操作的另一个特征是关联法则，即（A Join B）Join C等于A Join C，这并不难理解。接下来，让我们看一个例子。
    
     让我们以AdvyWorksSAMP数据库为例。我们为下面的查询生成实际的执行计划：
    
     1。代码中的加入顺序是联系人加入个人加入客户，但执行计划中的加入顺序是销售。客户加入销售。个人加入者。接触。
    
     从这里我们可以看到，代码中的Join顺序并不一定是最后一次执行计划的顺序，但是也证明了网络上的一些主要偏见是错误的：通过改变Join的顺序来提高性能。TS对加入顺序的决定和考虑。
    
     2。查询优化器根据大量信息决定执行哪个物理联接操作。在示例代码中，我们的联接都是逻辑的内部联接，但最终查询优化器选择适当的物理联接操作，如Merge Join for Sales。客户加入销售。单个的，因为两个表是基于聚合索引连接的，并且数据是根据聚合.index进行聚合以进行排序的（关于这一点，我们将在后面讨论）。
    
     当然，我们也可以使用Hint来要求查询优化器根据我们的需求强制执行Join生成的类型和顺序。让我们来看看下面的例子：
    
     我们当然可以通过使用Hint来改变查询优化器的行为，但是还需要注意每次执行的成本。ECT信息，如统计等。
    
     正如我们前面提到的，表的连接顺序随着表数量的增加而指数增加。实际上，只有几个表，并且连接顺序组合的数量将达到数万个。组合的数量主要取决于查询树的结构，并且查询优化器不能估计每个组合的成本，而是根据查询树的结构和形状使用启发式算法来减少搜索空间。
    
     在以往的文章中，曾经介绍过，经过一些处理之后，提交的查询语句将作为树结构出现在查询处理器中，这对查询优化器非常重要，树结构基本上可以分为：左深度树、右深度树、多路径树。
    
     例如，对于诸如：JOIN(JOIN(A，B，C)，D)之类的语句，可以生成左深度树或右深度树，如图所示：
    
     根据表的数量，Join的顺序生成许多不同的树形，最终导致不同的执行计划。
    
     太可怕了！左深度树的数量是基于N的！数字（n的拉斐尔函数，n的阶乘，其中n是表的数目）。对于多径树，数字是（2n2）！/（N1）！.
    
     此外，请记住，以上仅是生成的执行计划的可能数量。对于每个执行计划，查询优化器还选择不同的物理操作和数据访问方法（例如，表扫描、索引扫描、索引查找等），这些操作和数据访问方法乘以前一个执行计划。
    
     正在加载中，请稍候片刻