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)
-- 轉載請註明出處，更多請關注：http://blog.csdn.net/happyflystone
------------------------------------------------------------------------
一、關係引擎 relational engine
這個可以說是數據庫最重要的引擎之一，有的書也稱查詢處理器，簡單的說它完成對某個查詢進行分析並協調引擎內的相關組件以最優的方式進行工作，最終以OLE DB行集或非OLE DB行集與存儲引擎(storage engine)通訊進行存取數據。
在關係引擎內按其功能大體上可以分幾個主要的組件，重點說說命令解析及查詢優化器的工作。下面我們以圖來說明：
注：圖中的藍色箭頭是我根據自己的理解畫出來的，事實這些組件之間的工作是互相牽連、錯綜複雜的，如有不當希望指正
命令解析器：很顯然它是負責檢查T-SQL的語法正確性並轉譯成內部使用的查詢樹，在這時如果解析器無法識別時會立馬報錯並指出錯誤出處。我平時在使用的過程中經常會發現SQL拋出沒有準確標識的錯誤，這是因爲T-SQL本身沒有語法錯誤，命令解析器把它生成查詢樹，不再保存源碼格式的語句，在後續的執行中如果有錯誤發生自然無法定位源碼行信息。
查詢優化器：這個話題感興趣的人就多了，但是我得告訴大家的是SQL採用的取樣分佈統計數據評估成本的方式進行優化的，這勢必會帶來一些讓人不盡如意的時候。優化器所能做的是使用各種存取方法及策略解析查詢並生成相對成本最經濟的計劃。這個最經濟的計劃就有意思了，SQLSERVER並沒有採用徹底優化的方式，因爲對於一個複雜的查詢如果優化器檢查並評估每一個可能的計劃比選擇一個相對經濟的計劃並執行它耗時耗成本。最後SQL優化器採用了啓發式的修剪方式迴避徹底優化生成執行計劃，其實我們想呀，基於成本的優化本身這個過程就是耗時，如果優化都徹底實現最優化，對於一個查詢無論你如何實現它在性能上沒有了差異，嘿嘿，DBA失業也就不遠了。
查詢優化器首先從解析器獲取到查詢樹，首先判斷是否要優化，如果不需要優化的查詢樹直接生成內格式，比如控制流、DLL命令等。另外的被標識並進入實際執行優化階段，這部分被標識的語句大部分爲DML語句。優化過程大體如下：
Pseudo系統過程：SQL6.5以後的版本在關係引擎中加入了系統過程的二進代碼，如遊標運行機制的過程：sp_cursor、sp_cursoropen等以交互的方式解決難以標準的SQL語句，調用方式類似於存儲過程。
今天的任務完成，請大家繼續關注我的blog: http://blog.csdn.net/happyflystone