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