有几位朋友有这样的疑问：
select * |
照你所述的执行顺序，先要tab1和tab2进行笛卡尔乘积，再按照tab1.col1 = 123 and tab2.col1 = 'abc'进行筛选。这样的话，效率岂不是很低，数据库有这么愚蠢吗？
我想很多人都会有这个疑问，包括我在最初学习的时候也提出过这样的问题。那么，我的这篇文章就结合这个问题来讨论一下SQL Server的物理查询处理。首先我们必须明白逻辑处理和物理处理和区别，逻辑处理是指执行一个查询应该产生什么样的结果，那么逻辑查询的各个阶段就是这个查询从逻辑上执行的先后顺序，依照这个先后顺序就能得到正确的结果，正如我们做四则混合运算一样，先乘除后加减才能得到正确结果。
所以说逻辑查询只关心产生一个我们期望的、正确的结果，它并不关心产生这个结果需要多少的资源消耗。而物理处理就是怎么得到这个结果，这个时候才会考虑性能问题。下面我们就讨论下怎么执行这个物理处理的。
当一个查询到达数据库引擎的时候，数据库引擎需要做的是执行这个查询的查询计划，那么这个时候就存在两种情况，一种可能是这个查询的查询计划已经在缓存中，这种情况就直接执行这个查询计划。另外一种情况就是在缓存中找不到该查询的查询计划。没有怎么办？生成一个！怎么生成？
执行计划是在编译阶段生成的，编译需要经过三个步骤：分析、代数化（algebrization）、查询优化，看见没有这里的查询优化过程就能解决上面的朋友提出的先笛卡尔集在筛选造成性能低的问题。下面我就对这三个步骤作一个介绍。
***步：分析是检查语法并把SQL批处理转化成分析树的过程,如select * t1 where id in(1,2,3,4,5,6,7)在被分析树分析后就展开成了select * t1 where id=1 or id=2 or id=3 or id=4 or id=5 or id=6 or id=7 ,除此之外还有检查语法是否正确的功能。
第二步：接下的过程是代数化（algebrization），这个阶段使用SQL Server 2005的新组件algebrizer，algebrizer组件的主要功能是绑定，因此代数化过程通常称为绑定。这个阶段是将***步的分析树作为输入，生成被称为查询处理器树的输出，用于查询优化。其实这个阶段主要做几个事情，
一：运算符平展，简单的讲就是把二元运算符组合成N元运算符，这里必须给出一个示例才能很好的解释这个二元转换成N元如***步所示in操作展开成了一连串的or运算符，而分析器认为这些or都是二元的，也就是说它认为***个or 的左孩子是id=1,右孩子是 （id=2 or id=3 or id=4 or id=5 or id=6 or id=7 ）这个表达式，而右孩子又被认为是二元的，如此一来就必须进行一个递归过程。而运算符平展过程则将这种二元运算组合成n元运算符，就避免了递归的过程。
二：名称解析，这个过程其实就是检查这个查询中出现的表或者是表的列是不是在数据库中真实存在。以及在该查询过程中是不是可见的。三：类型派生，有点抽象，举个例子就能理解了，比如union查询吧，union左右两边查询结果对应位置的数据类型应该是一致的。四：聚合绑定和组分绑定，执行完这个步骤后查询处理器树便生成了。
第三步：查询优化，这个过程由查询优化器组件来完成的。查询中应该以何种顺序访问表，使用哪种方法和使用哪个索引，应该由哪个联接算法等都是由查询优化器组件来决定的，但是这个决定也不是随意的，它必须满足的前提条件是保证***得到的结果集必须是正确的，也就是说该结果集必须遵循逻辑处理的各个阶段所得到的结果集相同。优化器会尝试该查询的许多变体，一查找成本***的计划。
如果优化器分析该查询的元数据得知只有一个可执行的计划，那么它就不会再尝试寻求更好的计划，这个步骤叫做细微计划优化。如果没有找到细微计划优化，SQL Server将执行一些简化，简化就是对自身语法作一些转换，比如在联接前计算表的where筛选器，如前一篇描述的，逻辑查询中where筛选总是在联接之后计算，但是先计算where筛选器在联接同样能得到的正确的结果，而这样的效率往往是更高的，所以在物理处理中where往往在join前执行的，开篇提到的那个问题只是读者未理解逻辑处理和物理处理的差别而已。
到此为止，物理处理的各个步骤也做了一个简要的叙述，总结下，无论是存储过程还是即席查询都是执行的一个查询计划的副本，如果这个查询计划不存在的话就必须经过编译生成一个执行计划，在编译阶段必须经过分析，绑定（代数化），查询优化这些过程，最终得到我们需要查找的结果。关于查询优化组件具体是怎么优化查询处理器树的，我会在以后的篇幅作详细介绍。
【编辑推荐】
