我們知道，查詢優(yōu)化器的基本的目標就是為我們的查詢語句找出一個比較高效的執(zhí)行計劃。即使是一個非常簡單的查詢，也會存在很多的不同方式去訪問數(shù) 據(jù)，而這些不同的方式都是可以得到相同的結(jié)果的，所以，查詢優(yōu)化器必須要很“明智的”從這些大量的執(zhí)行計劃中找出了一個“最佳”的出來。
前一篇：淺析SQL Server查詢優(yōu)化器的工作原理
為了得到最好的計劃，查詢優(yōu)化器必須在某些條件的限制下，盡可能多的創(chuàng)建和評估大量的候選執(zhí)行計劃。看到這里，就有一點需要注意了“查詢優(yōu)化器是盡可能 多的創(chuàng)建候選執(zhí)行計劃”，而不是為一個查詢產(chǎn)生所有的執(zhí)行計劃。在SQL Server中，我們把一個查詢產(chǎn)生的候選執(zhí)行計劃的集合稱之為“搜索空間（search space）”。很顯然，搜索空間中的所有的執(zhí)行計劃都返回相同的結(jié)果。
給一張示意圖，讓大家更好理解一點，如下所示：
注：圖中的Search Space中的曲線代表執(zhí)行計劃
從理論上說，為了找到最佳的執(zhí)行計劃的查詢，基于成本的查詢優(yōu)化器應(yīng)該生成搜索空間中存在的所有可能的執(zhí)行計劃，并正確估計每個計劃的成本。然而，一些 復雜的查詢可能有成千上萬，或者甚至數(shù)百萬可能的執(zhí)行計劃，查詢優(yōu)化器不可能去產(chǎn)生并評估一個查詢的每一個候選的執(zhí)行計劃，如果那樣，評估所有計劃的時間 會非常的長，并且嚴重影響查詢的整體的執(zhí)行時間。
查詢優(yōu)化器必須優(yōu)化的時間和執(zhí)行計劃的質(zhì)量之間取得平衡。 例如，如果查詢優(yōu)化器花1秒鐘的時間找到了一個比較好的執(zhí)行計劃，并且這個計劃的執(zhí)行時間是1分鐘，那么這個時候，就沒有必要再去花費5分鐘的時間去為這 個查詢找更優(yōu)的執(zhí)行計劃。因此SQL Server不會做一個詳盡的全部查找，而是盡快找到一個合適的有效的計劃。由于查詢優(yōu)化器是有時間限制的，那么就可能選擇的計劃可能是最優(yōu)方案，也有可 能只是一些接近最優(yōu)的方案。
候選的執(zhí)行計劃是在查詢優(yōu)化器的內(nèi)部通過使用轉(zhuǎn)換規(guī)則，啟發(fā)式算法產(chǎn)生的。候選 的執(zhí)行計劃在優(yōu)化過程中一直保存在稱之為“Memo（中文翻譯可能為“備忘錄”，以后我們就直接使用英文名稱，很多的技術(shù)術(shù)語翻譯過來之后就變味了）”的 內(nèi)存組件中。從這里我們就可以知道：如果為了復雜的查詢產(chǎn)生所有的候選執(zhí)行計劃勢必會占用大量的內(nèi)存。
我們這里只是簡單的介紹一下候選執(zhí)行計劃的產(chǎn)生，后面我們會對每一個步驟進行詳細的分析。
執(zhí)行計劃成本估算
查詢優(yōu)化器需要為產(chǎn)生的候選的執(zhí)行計劃進行成本的估算，從而選擇一個成本最低的。為了估算一個計劃的成本，查詢優(yōu)化器會使用一些成本估算的公式來計算一 個計劃的成本，這些成本估算公式會考慮很多資源的使用，例如CPU，I/O，內(nèi)存等。成本估算主要是取決于算法中采用的物理操和估算的將要處理的數(shù)據(jù)記錄 的量（估算數(shù)據(jù)記錄的量也被稱之為“基數(shù)估算”）。
為了便于進行基數(shù)估算，SQL Server會使用并且維護統(tǒng)計數(shù)據(jù)（statistics），統(tǒng)計數(shù)據(jù)描述了表中數(shù)據(jù)的值的分布情況，或者簡單的理解為“元數(shù)據(jù)-描述數(shù)據(jù)的數(shù)據(jù)”。一 旦采用基數(shù)估算得出了嗎，每個操作的成本和對資源的要求，那么查詢優(yōu)化器就會將這個成本數(shù)值進行累計，從而得出整個就會的成本。我們這里不會討論過多與統(tǒng) 計數(shù)據(jù)相關(guān)的知識，在后面中會詳細的講述。
在下一篇文章中，我們會講述計劃的執(zhí)行與緩存，以及與Hint相關(guān)的話題。