擦亮自己的眼睛去看SQL Server之簡單選取
這篇文章主要和大家討論幾乎所有人都熟悉，但不少人又陌生的一條select語句。不知道大家有沒有想過到底是什么東西讓SQLServer能理解我們寫的select。這中間到底發生了什么，是不是有過沖動想去了解。至少我曾經沖動想去了解，但當時主要在研究CLR以及webform相關知識。后來主要精力放在研究SQLserver內部機制，今天就給大家介紹下這條語句。
一、范例數據庫腳本
- create database Test
- go
- alter database Test set recovery simple
- go
- use Test
- go
- create table Test
- (
- ID int identity(1,1) primary key,
- [Name] varchar(64) not null default '',
- CreatedTime datetime not null default getdate()
- )
- insert into Test([name]) values('xiaojun')
這個腳本就不介紹了，很簡單。
二、語句分析
- select * from Test
簡單吧，本來嘛標題就是之簡單語句。下面開始分析這條語句吧，假設讀者已經知道了SQLServer整體架構或者已經閱讀過這個系列第一篇文章。當這條語句被可靠的傳遞到關系引擎中的命令分析器，接下來就發生了：
分析：
從語法庫中檢查T-SQL進行基本的語法檢查。如果語法出錯了，那整個語句就立即停止，提示用戶語法出錯，哪出錯。比如錯誤使用的關鍵字、列、表名等。如果語法沒有出錯，就會生成一個分析樹傳遞給下一個步驟。
綁定：
1、名字解析：檢查所有的對象在用戶的安全上下文中存在并可見。這個步驟很好理解主要是數據庫每個對象都有權限。如果登錄的賬號沒有相應權限，就結束這個步驟。
2、類型推導：確定解析樹中每個節點的最終類型。這個步驟主要是補充分析分析步驟中的分析樹，確定其最終的類型。不知道大家可想過為什么要到這一步才確定。為什么不在分析中確定呢?主要原因是效率，類型推導會消耗資源，沒有必要在沒有確定用戶對每個對象有權限的情況下確定。那為什么不直接先確定用戶對每個對象有權限再做分析呢。那是因為沒做分析的時候，系統無法知道具體有哪些對象。我又要說了，SQLServer的設計真的可以說是很精致的，連這樣的細節和資源消耗都考慮了。值得我們學習哦。
3、聚合綁定：確定哪些地方可以進行聚合。這個步驟主要和SQL中是否有聚合操作有關系。
4、組合綁定：將聚合綁定到正確的選擇列表中。這個步驟是把聚合操作與需要聚合的列綁定對應起來。
這兩步操作主要是由命令分析器完成，它最終得到分析樹，傳遞給SQLServer引擎中最復雜最優技術含量的組件，沒有之一，查詢優化器。查詢優化器功能概況起來很簡單，就是優化SQL。具體優化模型如下：
優化：
1、檢查執行計劃緩存中是有沒對應的執行計劃。 如果沒有，繼續下面操作。如果有則使用緩存。SQL Server是根據SQL的哈希值比較的。想想為什么?
2、預優化：查詢語句很簡單，開銷足夠小，直接結束優化。比如沒有聯接的基本查詢。屬于零開銷，稱為普通計劃。比如我們這的select語句預優化就搞定了。
3、階段0：檢驗基本規則，以及散列和嵌套聯接選項。這個計劃的開銷是否小于0.2，如果是，結束優化。這里的0.2以及下面的1.0，這是SQLServer內部的開銷值，僅供SQLServer系統內部使用。
4、階段1：檢驗更多的規則，以及變換聯接的順序。如果開銷最小的計劃的開銷小于1.0，如果是，結束優化。如果不是，繼續判斷。如果maxdop>0且這個系統是SMP系統，以及最小開銷大于并行化的開銷臨界值，則使用并行計劃。比較并行計劃的開銷和最好的串行計劃的開銷，將開銷更小的計劃傳遞給階段2。
并行計劃是指優化器根據情況，將恰當的操作符拆分為數個可以同步運行的進程在不同的處理器上運行，需要多核支持。對于大數據量查詢可以提高效率。
maxdop是什么呢?這是SQLServer的一個高級配置。我們可以通過sp_configure查看。如下圖：
可能你直接運行sp_configure，看不到這個配置。主要是這是個高級配置項，默認不開啟。你運行以下語句后再運行sp_configure就能看到以上圖中信息。
- sp_configure 'show advanced options',1
- reconfigure
這里面的高級配置值，默認情況下不需要修改。必須你對SQLServer有較深理解，以及在修改前做好修改對整個SQLServer的影響的評估后才去改動。說說這個maxdop吧，這是說SQLServer在執行并行計劃的最大處理器數目，0代表由SQLServer決定。否則就是按照用戶指定的最大并行度。因此上面的maxdop>0且這個系統是SMP系統的意思就是當用戶修改了這個配置項，那么執行器在評估開銷時要優先考慮用戶修改過的最大并行度小的系統開銷。SMP系統是對稱處理器體系結構，基于Intel處理器的服務器基本上都是SMP系統。在此不展開說。
不知道大家注意到沒，我上面的圖查詢優化器輸出的是較好的執行計劃。想想為什么? 如果想查看優化過程的內部情況，可以使用一下sys.dm_exec_query_optimizer_info動態管理視圖。比如，下面演示證明我們這條select語句是屬于普通計劃。按照如下操作執行：
- dbcc freeproccache --清空執行計劃緩存
- select * from sys.dm_exec_query_optimizer_info where counter in('optimizations','trivial plan','search 0','search 1','search 2')
結果如下：
繼續：
- select * from Test
- select * from sys.dm_exec_query_optimizer_info where counter in('optimizations','trivial plan','search 0','search 1','search 2')
結果如下：
發現了吧，trival plan類型計數+1，說明優化器對select * from Test進行優化時是普通計劃。
5、階段2：檢驗所有可能的計劃，并且選擇達到檢驗的時間限制時開銷最小的計劃。
執行：這個計劃被調度執行，這個涉及到SQLOS不在本篇文章討論范圍，只要先簡單理解為交給CPU執行。
三、結尾
其中這個語句還有很多地方可以分析，比較在這條語句執行時，加鎖以及如何被調度執行。這些還是希望在放在后面的章節中解釋。這篇文章主要是談到了SQLServer如何對SQL進行解析優化的。仔細研究，你會發現SQLServer的查詢優化器做了很多優化措施當然其他數據庫也類似的組件。其實你會發現這些對于我們大部分開發人員都是屏蔽的。屏蔽是一種進步，java、.net的垃圾回收屏蔽了開發人員對內存的管理，那SQLServer在這里屏蔽了什么呢，這需要研究數據庫歷史。只有研究歷史，才能站在一個較高的角度知道現在的數據庫為什么是現在的樣子。
今天分析就到此結束，文中如有描述不當的地方，歡迎指出。共同進步才是硬道理。
【編輯推薦】
