本篇文章的議題如下：

• 查詢計(jì)劃概述
• 查詢解析
• 查詢優(yōu)化器
• 查詢執(zhí)行
• 查詢計(jì)劃的重用

查詢計(jì)劃概述

很多時(shí)候，當(dāng)我們?cè)谑褂胹ql server的時(shí)候，做的事情非常簡單：輸入sql語句，然后執(zhí)行，最后獲取結(jié)果。下面，為了使得大家更加清楚的了解Sql server的內(nèi)部機(jī)制，我們就重新來審視一個(gè)sql語句的執(zhí)行。

把sql語句提到給了之后，數(shù)據(jù)庫會(huì)執(zhí)行一系列的內(nèi)部處理，我們大致的可將內(nèi)部的處理按照?qǐng)?zhí)行的順序，劃分為兩個(gè)階段：

1. 發(fā)生在關(guān)系引擎中的操作
2. 發(fā)生在存儲(chǔ)引擎中的操作

在數(shù)據(jù)庫的關(guān)系引擎中，sql 的查詢語句會(huì)解析并且將解析的結(jié)果傳遞給后面的查詢優(yōu)化器，查詢優(yōu)化器負(fù)責(zé)生成執(zhí)行計(jì)劃。之后，執(zhí)行計(jì)劃(以二級(jí)制的格式)就會(huì)被傳遞到存儲(chǔ)引擎里面，最后返回或更新底層的數(shù)據(jù)。

數(shù)據(jù)庫的存儲(chǔ)引擎會(huì)進(jìn)行很多的操作，例如鎖定，索引的維護(hù)，事務(wù)的處理等。

因?yàn)楸鞠盗形恼轮饕钠饰鰣?zhí)行計(jì)劃，所以我們的關(guān)注點(diǎn)會(huì)放在關(guān)系引擎上面。

下面，我們就來稍微詳細(xì)的討論一個(gè)sql查詢語句的執(zhí)行過程。

查詢解析

正如我們剛剛提到過：當(dāng)把一個(gè)sql語句提交到了數(shù)據(jù)庫以后，sql語句最先會(huì)被傳入到關(guān)系引擎中。

當(dāng)sql語句達(dá)到了關(guān)系引擎之后，首先要進(jìn)行的操作就是檢查sql語句的格式是否正確。這個(gè)處理過程就是我們常說的“解析”過程。解析過程的結(jié)果就是生成一個(gè)解析樹，或者稱為查詢樹。查詢樹反映了一個(gè)查詢要執(zhí)行的邏輯步驟，查詢樹的結(jié)構(gòu)類似下面圖中所示：

其實(shí)從編譯原理的角度來看，這個(gè)解析過程就是文法和詞法的解析，最后生成語法樹。

有一點(diǎn)需要注意的就是：如果提交的sql語句不是一個(gè)數(shù)據(jù)操作語句(數(shù)據(jù)操作語句指Select，Insert，Update語句)，那么這個(gè)語句是不會(huì)被優(yōu)化的。例如，如果提交的sql語句是創(chuàng)建一個(gè)數(shù)據(jù)表，那么這個(gè)語句是不會(huì)被優(yōu)化的，而是直接執(zhí)行。

如果提交的數(shù)據(jù)操作語句，那么之前由關(guān)系引擎創(chuàng)建的解析樹就會(huì)傳遞給algebrizer組件執(zhí)行綁定過程。在這個(gè)綁定過程過程中，這個(gè)algebrizer組件就會(huì)去檢查解析樹中的表名，列名是否都關(guān)聯(lián)到了數(shù)據(jù)庫中相應(yīng)的表或?qū)ο蟮囊谩?/p>

同時(shí)，algebrizer組件還負(fù)責(zé)確定解析樹中的每個(gè)節(jié)點(diǎn)的類型是否和數(shù)據(jù)庫中對(duì)應(yīng)的是否一致。algebrizer組件以從下到上的方式開始遍歷樹，即，先從頁級(jí)節(jié)點(diǎn)開始，也就是列和常量。

綁定解析是一個(gè)非常重要的過程，在這個(gè)過程中還會(huì)識(shí)別出我們自己定義的一些別名。這個(gè)過程執(zhí)行完成之后，就會(huì)產(chǎn)生一個(gè)二進(jìn)制的“查詢處理樹”，這個(gè)樹會(huì)被傳遞給查詢優(yōu)化器。

查詢優(yōu)化器

查詢優(yōu)化器使用查詢處理樹和相關(guān)的統(tǒng)計(jì)信息來生成一個(gè)執(zhí)行計(jì)劃。

換句話說，查詢優(yōu)化器指出了如何最好的去執(zhí)行提交的sql語句。查詢優(yōu)化器會(huì)決定是否可以采用索引來訪問數(shù)據(jù)，采用那種類型的join操作會(huì)更好(例如，盡管我們有時(shí)候在sql中寫的是Left Join，可能查詢優(yōu)化器在分析之后，在保證結(jié)果一樣的前提下，采用Inner Join)。

查詢優(yōu)化器是一個(gè)基本成本分析的優(yōu)化器。這意味著它會(huì)嘗試為每個(gè)sql語句生成成本最低的執(zhí)行計(jì)劃。

另外，我們來歸對(duì)于優(yōu)化器所用到的統(tǒng)計(jì)數(shù)據(jù)進(jìn)行簡要的解析。所謂的統(tǒng)計(jì)數(shù)據(jù)，就是在數(shù)據(jù)庫中描述列、索引相關(guān)信息的數(shù)據(jù)，即數(shù)據(jù)的數(shù)據(jù)，或稱之為“元數(shù)據(jù)”。優(yōu)化器就是結(jié)合統(tǒng)計(jì)數(shù)據(jù)和查詢處理樹來進(jìn)行成本的估計(jì)的。

在默認(rèn)的情況下，統(tǒng)計(jì)信息是由數(shù)據(jù)庫內(nèi)部自動(dòng)的進(jìn)行更新的(在調(diào)優(yōu)的時(shí)候，可以手動(dòng)的更新)。

需要提及的就是：表變量是沒有任何的統(tǒng)計(jì)數(shù)據(jù)的，也就是說，如果對(duì)表變量中的數(shù)據(jù)進(jìn)行查詢，優(yōu)化器是不做任何的優(yōu)化的。但是臨時(shí)表是有相應(yīng)的統(tǒng)計(jì)數(shù)據(jù)的。

有一點(diǎn)需要注意的就是：上面的成本只是“估算”而已。一些復(fù)雜的語句可能會(huì)有很多個(gè)候選的執(zhí)行計(jì)劃，在這種情況下，查詢優(yōu)化器不會(huì)分析所有的組合，而是找出一個(gè)接近理論最小值的一個(gè)執(zhí)行計(jì)劃。計(jì)劃的成本表現(xiàn)為估計(jì)完成查詢所需的時(shí)間。最低估計(jì)成本不一定是最低的資源成本。

查詢執(zhí)行

一旦執(zhí)行計(jì)劃生成之后，操作就轉(zhuǎn)入存儲(chǔ)引擎中，這也是查詢真正被執(zhí)行的地方，也是根據(jù)估計(jì)執(zhí)行計(jì)劃 產(chǎn)生實(shí)際執(zhí)行計(jì)劃的產(chǎn)所。

查詢計(jì)劃的重用

從之前的一些步驟可以看到：Sql Server產(chǎn)生一個(gè)實(shí)際的執(zhí)行計(jì)劃需要很多的步驟和很多的成本(執(zhí)行計(jì)劃的過度編譯往往成為一個(gè)很大的性能問題)，必須盡可能的重用執(zhí)行計(jì)劃(如果后文不做特殊說明，執(zhí)行計(jì)劃就指代“實(shí)際執(zhí)行計(jì)劃”)，所以，在數(shù)據(jù)庫中，一旦執(zhí)行計(jì)劃產(chǎn)生之后，就被緩存在了內(nèi)存中(稱之為計(jì)劃緩沖)。

正如之前所提到的，當(dāng)優(yōu)化器產(chǎn)生了估計(jì)的執(zhí)行計(jì)劃之后，計(jì)劃就會(huì)被傳遞給存儲(chǔ)引擎。其實(shí)在將估計(jì)的執(zhí)行計(jì)劃傳給存儲(chǔ)引擎之前，查詢優(yōu)化器就去“計(jì)劃緩沖” 中查找與現(xiàn)在估計(jì)的執(zhí)行計(jì)劃對(duì)應(yīng)的實(shí)際執(zhí)行計(jì)劃。如果找到了，那么，查詢優(yōu)化器將會(huì)使用執(zhí)行計(jì)劃傳進(jìn)行后續(xù)操作。這樣就避免了重新生成實(shí)際的執(zhí)行計(jì)劃。

一般而言，每個(gè)查詢的執(zhí)行計(jì)劃都只保存一個(gè)，除非查詢優(yōu)化器知道采用并行執(zhí)行可以產(chǎn)生更好的性能，此時(shí)，并行查詢的執(zhí)行計(jì)劃就被緩存起來，也就是說：同一個(gè)查詢，在計(jì)劃緩沖中有兩個(gè)執(zhí)行計(jì)劃。

執(zhí)行計(jì)劃并不是永遠(yuǎn)被保存在內(nèi)存中的。它們也是會(huì)過期的。SQL Server會(huì)基于最近最少使用的算法來移除那些不常用的執(zhí)行計(jì)劃。下面列出了執(zhí)行計(jì)劃被移除的幾個(gè)條件：

1. 系統(tǒng)產(chǎn)生了內(nèi)存壓力，需要更多的內(nèi)存，此時(shí)迫使SQL Server釋放自己占用的內(nèi)存。
2. 內(nèi)存中的執(zhí)行計(jì)劃的最近使用次數(shù)為0.
3. 執(zhí)行計(jì)劃沒有被現(xiàn)在的數(shù)據(jù)庫連接引用。

注:熟悉.NET的朋友，可以將之與.NET的垃圾回收機(jī)制類比理解。

今天就到這里，下一篇，我們將對(duì)執(zhí)行計(jì)劃進(jìn)行更多的分析!

原文鏈接：http://www.cnblogs.com/yanyangtian/archive/2011/09/01/2162188.html

【編輯推薦】

1. 數(shù)據(jù)挖掘中易犯的幾大錯(cuò)誤
2. 整理索引碎片，提升SQL Server速度
3. 大數(shù)據(jù)平臺(tái)：探索數(shù)據(jù)價(jià)值
4. Big Data技術(shù)綜述
5. SQL Server引入Hadoop大數(shù)據(jù)處理能力