SQL2005数据库引擎结构（二）

------------------------------------------------------------------------

-- Author : HappyFlyStone

-- Date   : 2009-09-21 17:36:30

-- Version: Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86)

--      Apr 14 2006 01:12:25

--           Copyright (c) 1988-2005 Microsoft Corporation

--           Enterprise Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

--      转载请注明出处&＃xff0c;更多请关注&＃xff1a;http://blog.csdn.net/happyflystone

------------------------------------------------------------------------

一、关系引擎　relational engine

这个可以说是数据库最重要的引擎之一&＃xff0c;有的书也称查询处理器&＃xff0c;简单的说它完成对某个查询进行分析并协调引擎内的相关组件以最优的方式进行工作&＃xff0c;最终以OLE DB行集或非OLE DB行集与存储引擎(storage engine)通讯进行存取数据。

在关系引擎内按其功能大体上可以分几个主要的组件&＃xff0c;重点说说命令解析及查询优化器的工作。下面我们以图来说明&＃xff1a;

注&＃xff1a;图中的蓝色箭头是我根据自己的理解画出来的&＃xff0c;事实这些组件之间的工作是互相牵连、错综复杂的&＃xff0c;如有不当希望指正

命令解析器&＃xff1a;很显然它是负责检查T-SQL的语法正确性并转译成内部使用的查询树&＃xff0c;在这时如果解析器无法识别时会立马报错并指出错误出处。我平时在使用的过程中经常会发现SQL抛出没有准确标识的错误&＃xff0c;这是因为T-SQL本身没有语法错误&＃xff0c;命令解析器把它生成查询树&＃xff0c;不再保存源码格式的语句&＃xff0c;在后续的执行中如果有错误发生自然无法定位源码行信息。
    查询优化器&＃xff1a;这个话题感兴趣的人就多了&＃xff0c;但是我得告诉大家的是SQL采用的取样分布统计数据评估成本的方式进行优化的&＃xff0c;这势必会带来一些让人不尽如意的时候。优化器所能做的是使用各种存取方法及策略解析查询并生成相对成本最经济的计划。这个最经济的计划就有意思了&＃xff0c;SQLSERVER并没有采用彻底优化的方式&＃xff0c;因为对于一个复杂的查询如果优化器检查并评估每一个可能的计划比选择一个相对经济的计划并执行它耗时耗成本。最后SQL优化器采用了启发式的修剪方式回避彻底优化生成执行计划&＃xff0c;其实我们想呀&＃xff0c;基于成本的优化本身这个过程就是耗时&＃xff0c;如果优化都彻底实现最优化&＃xff0c;对于一个查询无论你如何实现它在性能上没有了差异&＃xff0c;嘿嘿&＃xff0c;DBA失业也就不远了。

查询优化器首先从解析器获取到查询树&＃xff0c;首先判断是否要优化&＃xff0c;如果不需要优化的查询树直接生成内格式&＃xff0c;比如控制流、DLL命令等。另外的被标识并进入实际执行优化阶段&＃xff0c;这部分被标识的语句大部分为DML语句。优化过程大体如下&＃xff1a;

Pseudo系统过程&＃xff1a;SQL6.5以后的版本在关系引擎中加入了系统过程的二进代码&＃xff0c;如游标运行机制的过程&＃xff1a;sp_cursor、sp_cursoropen等以交互的方式解决难以标准的SQL语句&＃xff0c;调用方式类似于存储过程。