SQL Server Architecture--PART II，基本的SELECT查询流程

一，前言     

       本部分介绍MS SQL SERVER在处理一个基本的SELECT语句时采取的处理步骤

二，一个简单的SELECT语句处理图

    

三，基本SELECT语句处理步骤

    1.  SQL Server客户端SNI与SQL Server服务器端SNI使用某种通信协议，比如TCP/IP，建立连接。然后，客户端基于此通信协议，在此通信协议的TDS端点上建立连接，接着，客户端将SELECT语句封装成 TDS message发往SQL Server服务器。

    2. SQL Server端的SNI接收此TDS message并解包，并判断出这是个SELECT语句，然后将此SELECT语句与“SQL Command” 字样发送给Command           Parser.Command Parser(命令解析器),主要负责对SQL语句做语法分析并生成代数树。

    3. Command Parser 检查计划缓存(plan cache,是 buffer pool的一部分)，看在计划缓存中是否存在与此SELECT相match的、可重用的执行计划，如果找到，则将找到的执行计划交给Query Executor,否则，Command Parser就为此select语句生成查询树，并将查询树传给查询优化器以便产生查询计划。

    4. 查询优化器(Query Optimizer，以下简称QO)接到需要优化的SELECT语句后，按如下规则优化SQL：

           A、首先，QO启动pre-optimization阶段，此阶段主要针对那些没有join的，非常简单的SQL语句，对于这样的语句，SQL SERVER可以在0成本的                  情况下产生“zero cost” 执行计划，这种执行计划叫做trivial plans；

           B，如果需要优化的SQL语句不符合产生trivial plans的条件，则SQL SERVER执行stage 2，以产生一个执行计划：

                  ➤Phase 0 — During this phase the optimizer looks at nested loop joins and won’t consider parallel operators.

                                    The optimizer will stop here if the cost of the plan it has found is < 0.2. A plan generated at this phase is known as a                                                transaction processing, or TP, plan.

➤ Phase 1 — Phase 1 uses a subset of the possible optimization rules and looks for common patterns for which it already has a plan.

    The optimizer will stop here if the cost of the plan it has found is < 1.0. Plans generated in this phase are called quick plans.

➤ Phase 2 — This final phase is where the optimizer pulls out all the stops and is able to use all of its optimization rules. It also looks at    parallelism and indexed views (if you’re running Enterprise Edition).

           

                Completion of Phase 2 is a balance between the cost of the plan found versus the time spent optimizing. Plans created in this phase               have an optimization level of “Full.”

             注：QO在为SQL语句找寻执行计划时，不是必须要找到一个最好的执行计划，而是要找到一个足够好的计划就行。试想一下如下情况，100个

                    表做JOIN,本身就有N多执行计划，QO要找出最好的执行计划所耗费的资源和时间，很可能远远超过使用一个足够好的执行计划所耗费的

                    资源和执行时间.

  

      5. 在执行的时候， Query Executor (QE)确定要完成查询计划，需要读取哪些数据，因此QE通过OLE DB interface(Rational Engine和Storage Engine之间的通信接口)将请求发给Storage Engine的Access  Methods;

    6. Access Methods为了完成来自QE的请求，需要读取来自database的页面，因此，QE向 Buffer Manager请求数据库页面.

    7. Buffer Manager 接到请求后，检查buffer pool的data cache，看看需要的页面是否已经cache在data cache中，如果已经在data cache，则将页面返回给Access Methods，如果需要的页面没有在data cache中，则产生hard page Fault，从磁盘将需要的页面调入data cache中(这个时候会产生PAGEIOLATCH_*类的LATCH)  。

    8. 最后,Access Methods将结果集合返回给关系引擎(Relational Engine),关系引擎再将结果集以TDS message发送给客户端。

select.jpg

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/101629/viewspace-762108/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/101629/viewspace-762108/