理解SQL Server是如何執行查詢的 (3/3)

• 頁併發訪問的保護：閂鎖

  在多線程併發狀況下，須要防止讀線程讀到寫線程正在寫的資源，在編程中，經過使用互斥器(Mutexes), 信號量(Semaphore), 臨界區(Critical Section)和事件(Event Object)來保護資源，而這些機制在SQL Server中被統一表示爲閂鎖。

  閂鎖自己是一種數據結構，用於保護併發訪問中的資源。閂鎖有多種模式，不一樣模式的兼容性不一。模式和兼容矩陣以下：

  • KP – Keep Latch 保證引用的結構不能被破壞
  • SH – Shared Latch, 讀數據頁的時候須要
  • UP – Update Latch 更改數據頁的時候須要
  • EX – Exclusive Latch 獨佔模式，主要用於寫數據頁的時候須要
  • DT – Destroy Latch 在破壞引用的數據結構時所須要

  --	KP	SH	UP	EX	EX	DT
  KP	Y	Y	Y	Y	Y	N
  SH	Y	Y	Y	Y	N	N
  UP	Y	Y	N	N	N	N
  EX	Y	N	N	N	N	N
  DT	N	N	N	N	N	N

  關於閂鎖，更多內容：關於閂鎖

• 鎖

  閂鎖是線程併發時保護物理頁的機制，鎖(Lock)是事務併發時對邏輯頁的保護機制。

  • 邏輯 VS. 物理
    鎖是一個6字節長的字符串，它自己並非被鎖定的對象，只是描述了哪一個對象被鎖定了。閂鎖是在內存中被鎖住的一個實際對象。獲取閂鎖須要獲取實際被鎖住的對象，獲取鎖只須要組織相應的6字節字符串，而後向鎖管理器請求某個鎖。

  • 線程 VS. 事務
    閂鎖由進程中的線程獲取和釋放，而鎖由事務獲取和釋放。而一個事務可能使用多個線程，如並行查詢，查詢中的子查詢被不一樣的工做線程執行等。

  鎖模式有不少種，只經過其名稱，有時很難明白其含義。下面簡單解釋一下各類鎖模式。

  1. 架構穩定鎖
     當查詢計劃執行時須要確保它所引用的各類對象(e.g 表、索引)的結構不會被其它查詢修改，因而在查詢開始執行時，須要獲取全部被引用對象的」架構穩定鎖「，實際是SCH-S鎖。對於DDL語句，須要獲取對象上SCH-M鎖，它幾乎與全部的鎖模式都不兼容。

     SCH-S它一般是在查詢編譯時獲取，編譯完成後，一般只是看到IS鎖。SCH-M在對象修改的整個過程都被持有，在這期間任何別的查詢都沒法獲取這個對象上的鎖。BY Joe .TJ

  2. 共享鎖、更新鎖和排它鎖
     基本的鎖模式包括共享鎖(S),排它鎖(X)和更新鎖(U)。S和X鎖，顧名思義。更新數據時，須要先找到將被更新的數據行，這些被找到的數據行就被加上U鎖，而後將U鎖升級成X鎖，再更新行或者刪除後插入行。U鎖與數據讀取類型的鎖模式是兼容，即不阻塞讀操做，同時減小了更新死鎖的發生。

  3. 鎖的層次結構和意向鎖
     鎖模式名稱前有「I」的都是意向鎖，理解意向鎖前要先明白鎖的層次結構。以掃描一個包含數百萬行的表爲例。若是每一行獲取一個S鎖，則須要數百萬個S鎖，顯然開銷會很是大。因此查詢決定不獲取行鎖，而獲取表上的S鎖。這時，若是有一個併發的查詢，須要刪除表中的某一行，因而須要獲取一個X行鎖。好了，問題來了：由於有了表級的S鎖，鎖管理器如何才能知道不能分配X行鎖給這個刪除操做？鎖只是一個描述什麼對象被 鎖住了的字符串，鎖管理器沒有辦法能過刪除操做發來的X行鎖字符串判斷出：表上已經有S表鎖，不能分配請求的X行鎖。爲了解決這種問題，因而有了意向鎖。刪除操做知道要刪除的行屬於哪個表，在獲取X行鎖前，須要獲取行的上層對象的IX鎖，即表的IX鎖。而IX鎖和S鎖是兼容，因而兩個事務中的其一必須等待另外一個完成才能開始。這樣就解決了這個問題。
     一樣還有一類轉換鎖，如SIX,UIX等。好比SIX表示，用S鎖模式鎖定了表，而且可能鎖定下級的某個行。

     關於轉換鎖的更多資料，分析SIX鎖和鎖分區致使的死鎖

  4. 鍵範圍鎖

     鎖模式名稱前有「R」的都是鍵範圍鎖。鍵範圍鎖須要在可序列化隔離級別下，它隱式地保護當前事務中已經讀取的行集範圍不實被其它事務修改。其它也是可序列化的要求，事務中讀取的數據，從頭至尾都要一致，不容許幻讀和幻插入。還有一點要注意，既然是」鍵「，那就是針對索引，即必需經過索引肯定鍵範圍，才能使用鍵範圍鎖。

     在默認的已提交讀隔離級別下，有種狀況會使用到鍵範圍鎖：主外鍵關係的表中，若是設置了外鍵的級聯刪除，則刪除主鍵表時，被級聯刪除的外鍵表的行會使用鍵範圍鎖。BY Joe .TJ

• 數據寫入

  數據修改操做方式和數據查詢操做相似，包括插入，更新和刪除等。數據修改操做符調用next()時，先定位到要修改的數據的位置(對於插入，則是定位到插入數據的新位置)，而後作相應的修改操做。而後再調用next()修改下一行，如此往復。刪除和更新操做一般被讀操做所驅動，當讀取操做符定位到要被刪除或者更新的行，而後將行的書籤傳給刪除或者更新操做符執行操做。SQL Server 使用日誌預寫( Write Ahead Logging )機制保證，每一個數據修改操做完前要先寫事務日誌。數據修改的簡單流程以下：

  1. 操做符先定位到將要修改的數據所在的頁。一樣，頁必須要在緩存池中。

  2. 操做符須要獲取頁上的排它閂鎖，避免其它操做符讀取到些頁。

  3. 操做符生成修改操做的事務日誌，而後寫入到日誌文件(實際是寫入到日誌緩存區，尚未寫入到磁盤上的日誌文件)。

  4. 操做符修改緩存池中的數據頁。

  5. 在開始數據修改前，將前面日誌的LSN寫入到數據頁的頁頭做爲」最後修改操做的LSN(Last Modified LSN)「。
  6. 釋放頁上的排它閂鎖，其它的操做符能夠讀取這一頁了。注意，直到這一步，全部操做都是發生在內存中，沒有任何磁盤操做發生。
  7. 在數據修改事務提交前，必須生成一條日誌用於表示此事務已經提交了。而後將這些日誌寫到磁盤上的日誌文件，這樣完成了事務的持久化。若是這時發生系統崩潰，在恢復時，恢復進程會REDO這些已經提交的事務。

  8. SQL Server 經過Checkpoint週期性將緩存池中的髒頁寫到數據文件。

  有一種數據寫入的流程與上面描述的有一些差異：最小化日誌化(minimally logged write)。只有插入新數據的操做可以被最小日誌化，例如：INSERT，使用UPDATE中的 .WRITE()向blob類型的列追加數據。最小化日誌操做還必須知足一些其它的條件，才能發生。它在寫數據的簡單流程以下：

  1. 分配新的頁給正在執行執行最小化日誌操做(BULK操做符)。
  2. 操做符從緩存池定位到分配給它的新頁，而後獲取它的排它閂鎖。
  3. 生成一條日誌記錄此頁已經用於最小化日誌的大容量插入操做。而後這條日誌被追加到日誌中(在日誌緩衝區)，再將這條日誌的LSN寫入到頁頭，做爲最後修改操做的LSN.
  4. 頁被添加到事務中的最小化日誌頁列表中。
  5. 如今操做符就開始向頁中添加更多的行。這個過程當中，不須要爲每一行插入生成一條日誌。只是寫入緩存池中的頁，如今尚未寫入到磁盤。
  6. 當一頁被寫滿，就重複前面的流程分配新頁而後再寫入數據。
  7. 在最小化日誌操做事務提交前，必須將全部被修改的數據頁先寫入到磁盤。當數據頁寫入磁盤完成後，會生成同樣用於表示事務已提交的日誌，而後將這條日誌追加到日誌文件中(日誌緩衝區)。再將全部相關的日誌寫入到磁盤上的日誌文件。
  8. 爲了不「驚羣效應」，即全部被修改的數據頁在事務提交前同時寫入數據文件。爲了不之種狀況，SQL Server 使用一個叫積極寫(Eager Write)的進程將髒頁定入磁盤。積極寫進程能夠在事務提交前交髒頁寫到磁盤。

  最小日誌操做也是事務性的，知足事務的ACID屬性。

  關於最小化日誌操做的更多資料：導數中的最小化日誌記錄：背景和理論

• DDL

  並非全部的T-SQL語句都使用在執行計劃樹中迭代操做符的方式執行。最典型的就是DDL語句，例如CREATE TABLE。SQL Server 將數據庫中全部對象的元數據存儲在內部系統表中，因此任何數據庫對象級的操做(如建立表，新增行，刪除表等等)都是要經過操做這些元數據來實現。大約有80個內部系統表，它們涵蓋了objects, procedures, functions, schemas, users, logins, certificates, views, partitions, permissions, databases, files等全部數據庫對象的元數據。雖然DDL不直接使用操做符，可是它直接使用實現操做符的代碼來高效地訪問內部系統表數據。例如，DDL不調用Seek操做符的next(),而是使用實現Seek操做符中next()的代碼去定位數據。DDL經過更新、刪除和插入內部系統表的數據來完成自身的操做。有一些DDL還去完成一些系統表外的操做，如在磁盤上建立文件，與Windows集羣API協做配置AG等。還有一些DDL須要維護用戶表內的數據，如加載新添加的列的默認值，檢查現有的數據數據是否符合新加的約束等。

• BACKUP, RESTORE 和 DBCC

  歸納的說，BACKUP和RESTORE是複製一個文件到一個文件。BACKUP是把數據文件和日誌文件複製到備份文件，RESTORE是把備份文件複製到數據文件和日誌文件，當作它們還會處理一些內部系統表的工做。而DBCC 每一個命令的行爲都不太同樣，推薦閱讀 CHECKDB from every angle 來了解更多信息。

• 我知道這些有什麼用？

  數據庫開發者主要面對兩種問題：性能調優和解決數據丟失問題。知道這些對後者沒有什麼多大的用處，但對前者有幫助。一旦你明白，服務器會給每個客戶端發來的請求建立一個任務(Task)線程，性能問題就會被簡化爲：任什麼時候刻，任務要麼在執行，要麼在等待。而每一次等待的信息都會被SQL Server 內部會收集起來。推薦一個白皮書，其中有一個很是好的方法論指導如何使用等待信息排查性能瓶頸問題：Performance Tuning Waits Queues