計划緩存（Plan Cache）
如果SQL Server已經找到一個好的方式去執行一段代碼時，應該把它作為隨后的請求重用，因為生成執行計划是耗費時間且資源密集的，這樣做是有有意義的。
如果沒找到被緩存的計划，然后命令分析器（Command Parser）在T-SQL基礎上生成一個查詢樹（query tree）。查詢樹（query tree）的內部結構是通過樹上的每個結點代表查詢中需要的執行操作。這個樹然后被傳給查詢優化器（Query Optimizer）去處理。我們的簡單查詢沒有一個存在的計划，因此一個查詢樹（query tree）會被創建，然后傳給查詢優化器（Query Optimizer）。
上圖展示了命令分析器（Command Parser）是用來檢查現存執行計划的計划緩存（plan cache），因為在緩存里沒找到我們查詢的任何信息，還有從命令分析器（Command Parser）輸出傳給優化器的查詢樹（query tree）。
查詢優化器（Query Optimizer）是被SQL Server團隊視為最有價值的財產，也是產品中最復雜、機密的部分之一。幸運的是，只有底層的算法和源代碼被很好保護（即使在微軟內部），優化器如何工作才能被研究和監視。
這個所謂的基於成本（cost-based）的優化器，意味要去評估執行查詢的各種方式，然后選擇被認為擁有最小成本的方式去執行。執行方式以查詢計划（query plan）實現並從查詢優化器（Query Optimizer）輸出。
基於剛才的介紹，你認為優化器的工作是找到最好的查詢計划會被原諒的，因為那看起來是很明顯的設想。然而它的實際工作是在一段時間內找到好的計划，而不是最佳計划。優化器的目標通常被描述為找最有效率的計划。
如果優化器每次都嘗試去找最好的計划，比起執行一個慢的計划，找個最好的計划花費的時間更長（一些內建的試探法實際上在保證優化器從不花更長的時間找到好計划，而是就找一個計划並執行它）。
優化器同樣在成本的基礎執行多級優化，在每一階段增加更多可用選擇項來找更好的計划。當一個好計划被找到時，優化器就停在那一階段了。
第1階段被稱之為預優化，當語句是足夠簡單而只有一個最佳計划時，在第一階段就退出剩下的步驟，移除額外成本需要。沒有join的基本查詢被認為簡單，計划成本產出為0，然后被提及為普通計划（trivial plans）。
優化實際上開始的下一階段包含三個查找時期：
- 第0時期——這個時期優化器會找內循環連接（nested loop joins）且不考慮並行運算符（parallel operators）。
如果已經找到的計划成本小於0.2，優化器會停在這里。在這個階段生成的計划稱為事務處理（transaction processing）或簡稱TP計划。
- 第1時期——第1時期使用可用優化規則的子集來找常用格式（common patterns）的已有計划。
如果已經知道的計划成本小於1.0，優化器會停在這里。這個階段生成的計划被稱為快速計划（quick plans）。
- 第2時期——在這個最后時期優化器全力以赴（pulls out all the stops）使用它所有的優化規則。它同樣也會找下並行（parallelism）和索引視圖（indexed views）（如果你運行的是企業版（Enterprise Edition））。
第2時期的完成是找到計划的成本對優化需要的時間之間的平衡。在這個時期生成的計划有完全級別（level of "Full"）的優化。
它的花費需要多少？
這里提及的花費不能用多少秒或其他有意義的表達來衡量；它只是標記代表計划資源消耗值的一個任意數。然而，在早期的微軟SQL Server世界里，它的起源是在桌面電腦上的基准檢查程序（benchmark）（跑分)。
在計划里，每個運算符都有一個底線成本，然后用它來乘以行的大小和預計行數來獲得那個運算符的成本，計划成本就是這些所有運算符的成本。
因為成本來自於底線值且與你的硬件速度無關，在每個SQL Server裝置（同比版本 like-for-like version。博主注：與版本無關。）里生成每個計划的成本是一樣的。
因為我們的SELECT查詢非常簡單，它退出在預優化時期的操作，因為這個計划對優化器非常明顯（一個普通計划）。現在已經有查詢計划了，它向查詢執行器（Query Executor）去執行。
查詢執行器（Query Executor）
查詢執行器的工作是不釋自明的，它執行查詢。更准確的說，它通過干完包含與存儲引擎相互作用的檢索或修改數據的每一步來執行查詢。
（此處有信息需要完善…………）
這個SELECT查詢需要檢索數據，因此請求傳給存儲引擎（Storage Engine）通過OLE DB接口傳給存取方法（Access Methods）。
上圖展示了作為優化器的輸出的執行計划（query plan）正傳給查詢執行器（Query Executor），同時引入了存儲引擎（Storage Engine），它被查詢執行器（Query Executor）通過OLE作為接口給存取方法（Access Methods）。
存取方法（Access Methods）
存取方法是為你數據和索引提供存儲結構，還有通過數據檢索或數據修改接口的一批代碼。它包含檢索數據的所有代碼單本身不執行操作，它向緩存區管理器（Buffer Manager）傳遞請求。
假設我們的SELECT語句需要讀取一些記錄行的數據剛好在一頁。存取方法（Access Methods）的代碼會讓緩存區管理器（Buffer Manager）檢索頁，因此它可以准備一個OLE DB的記錄集傳回給關系引擎（Relational Engine）。
緩存區管理器（Buffer Manager）
緩存區管理器（Buffer Manager），如名所示，管理緩沖池（buffer pool），它代表着SQL Server的主要內存使用。如果你需要從頁讀一些記錄行（當我們談論UPDATE查詢時會提及修改數據），緩存區管理器（Buffer Manager）在緩沖池（buffer pool）檢查數據緩存看看在內存里是否有被緩存的這頁。如果這頁已被緩存了，結果就會傳回給存取方法（Access Methods）。
如果這頁沒被緩存，然后緩存區管理器（Buffer Manager）從磁盤里拿這頁，把它放入數據緩存（Data Cache），然后把結果傳回給存取方法（Access Methods）。
你這里要記住的要點是你永遠只和內存中的數據打交道。在作為記錄集返回前，你請求的每個新的數據讀取，首先從磁盤讀取，然后寫回內存（數據緩存（the data cache））。
這就是為什么SQL Server需要在內存里保持最小級別的可用頁面；如果第一時間在緩存里沒有空間來放數據，你就不能讀取任何新數據。
存取方法（Access Methods）代碼決定SELECT查詢需要一個新頁，因此它向緩存區管理器（Buffer Manager）拿。緩存區管理器（Buffer Manager）檢查它是否已在數據緩存（data cache），如果沒找到的話就從磁盤加載到緩存。
數據緩存（Data Cache）
數據緩存一直是緩沖池（buffer pool）最大一部分；因此也是在SQL Server最大內存用戶。這里每個從磁盤讀取的數據頁在被用之前都會被寫回。
這個sys.dm_os_buffer_descriptors動態管理視圖（DMV）每一行代表當前內存持有的每個數據頁，你可以用這個腳本看看在數據緩存區（Data Cache）每個數據庫占用多少空間：
1 SELECT count(*)*8/1024 AS 'Cached Size (MB)' 2 ,CASE database_id 3 WHEN 32767 THEN 'ResourceDb' 4 ELSE db_name(database_id) 5 END AS 'Database' 6 FROM sys.dm_os_buffer_descriptors 7 GROUP BY db_name(database_id),database_id 8 ORDER BY 'Cached Size (MB)' DESC
輸出結果看起來會類似如下：
Cached Size (MB) Database
3287 People
34 tempdb
12 ResourceDb
4 msdb
這個例子里，People數據庫在數據緩存（Data Cache）里有3287 MB數據頁。
頁在緩存里停留時間量由最近最少使用（least recently used：LRU）策略決定。
（此處有信息待完善………………）
一個簡單SELECT語句（查詢）生命周期總結
SELECT查詢的整個生命周期在這里被介紹：
- 在客戶端的SQL Server網絡接口（SNI）與在SQL Server使用例如TCP/IP的網絡協議的網絡接口（SNI）建立連接。然后在TCP/IP連接上建立與TDS終結點的聯系並發送SELECT語句作為TDS消息發送給SQL Server。
- 在SQL Server上的SNI把TDS消息拆包，讀取SELECT語句，傳送一個“SQL命令”給命令分析器。
- 命令分析器在緩沖池檢查計划緩存是否存在，與語句匹配的可用查詢計划被命令分析器接收。如果沒有找到它，基於SELECT語句創建查詢樹傳給優化器來生成查詢計划。
- 優化器在預編譯生成零成本計划或普通計划，因為這個語句太簡單了。生成的查詢計划然后傳給查詢執行器去執行。
- 在執行時，查詢執行器決定讀取需要的數據來完整這個查詢計划，因此通過OLE DB接口把請求傳給在存儲引擎里的存取方法。
- 存取方法需要從數據庫里讀一個頁來完成來自查詢執行器的請求，它讓緩存區管理器來提供這個頁。
- 緩存區管理器檢查數據緩存看看它在緩存里是否已有。它不在緩存，因此從磁盤里拿這個頁，放入緩存，傳回給存取方法。
- 最后，存取方法把結果集送回給關系引擎發回給客戶端。