擦亮自己的眼睛去看SQL Server之簡單Insert
本來是打算先寫SQLServer歷史的，不過感覺寫那部分內容比較難還需要多查些資料。于是調整了下順序寫下簡單的Insert語句。數據庫結構還是采用上一篇的結構。具體查看上一篇文章擦亮自己的眼睛去看SQL Server之簡單Select。今天討論的語句也比較簡單，Insert語句。
一、Insert腳本
- insert into Test([Name]) values('xiaojun')
沒什么好說的，因為想寫這樣的語句太簡單。
二、 語句分析
這條語句到底發生了什么呢?假設讀者已經知道了SQLServer整體架構或者已經閱讀過這個系列第一篇文章。當這條語句被可靠的傳遞到關系引擎中后已經生成執行計劃，并且開始被調度執行。接下來就發生了：
寫事務日志：數據修改事務中唯一一個總是需要寫入磁盤的操作。并不是修改查詢語句的清單，而是修改操作發生之后數據頁面的具體變化。是由日志管理器完成。看到寫入磁盤，我們應該立刻聯想到性能問題，因為這個操作是總是寫入磁盤。如果一條語句的操作的數據很大的話，這個耗時是十分可怕的。舉個例子：如果想知道這個差距，你可以在百萬或者千萬的表中執行以下兩條語句體會以下：truncate table Test以及delete from Test。當然嚴謹的同學會說truncate是針對區操作，delete是針對頁操作，truncate的鎖消耗也比delete的鎖消耗少。這些是會導致truncate比delete快的原因。但是這些原因不是主要原因，主要原因就是這里說的寫事務日志，delete是每次刪除一行，并在事務日志中為所刪除的每行記錄一項，而truncate是通過釋放存儲表數據所用的數據頁來刪除數據，并且只在事務日志中記錄頁的釋放。既然事務日志會影響性能，為什么還記錄呢?主要解決保護數據以及數據一致性的問題。
接收寫請求：一旦訪問方法接收到寫事務日志成功的確認信息，就會接收寫請求，將寫請求發送緩存區管理器。注意了，這里是把請求交給緩存區管理器，緩存區管理器只是操作緩存跟物理文件沒有任何關系。這里強調的目的是，如果沒有理解這里說的原理的話。你可能會為自己做了大量的插入操作，而數據文件的大小沒有任何變化而感到匪夷所思。訪問方法表面上起了請求傳遞的作用，其實它很智能有一些比較復雜的算法來預測執行情況。
插入緩沖池：緩沖區管理器在內存中插入數據，插入成功后將確認結果發送給訪問方法，最終確認結果到達客戶端。
寫入數據文件：這個步驟可以由兩個組件任何一個完成。惰性寫入器線程定期檢查SQLServer空閑緩沖列表的大小，當這個值過低的時候，惰性寫入器會掃描整個數據緩存，將所有一段時間沒被使用的頁面老化。如果找到一段時間沒有被使用的臟頁，惰性寫入器則將其寫入磁盤并且刪除，然后將這個頁面的內存空間標記為空閑空間。惰性寫入器還會監測服務器上的空閑物理內存，如果內存很少它會將SQLServer的空閑緩沖列表釋放給windows，在SQLServer負載很重時，它還會在服務器有空閑物理內存且已給SQLServer分配的內存還沒有達到我們配置的最大服務器內存(max server memory)時增加SQLServer的空閑緩沖列表以適應負載。檢查點是檢查點線程創建的一個時間點，將保證臟頁都寫入磁盤，并且在頁面頭將緩存中的這個頁面標記為干凈的頁面注意檢查點是不刪除臟頁的。至于檢查點的執行時間是要分幾種情況的：如果你配置了recovery interval(min)，就以這個為準。如果沒有配置，并且這上一次檢查點結束后寫入的事務日志數據超過10MB，則大約每分鐘啟動一致。還比如，我們人為執行checkpoint執行，或者執行備份重啟命令都會觸發檢查點。拋開我們人為操作，這個具體時間確實無法確定，SQLServer有內部啟發算法控制這個值。不過我們可以開啟一個跟蹤標志3502能查看。這個跟蹤標志在錯誤日志中記錄了檢查點的開始與結束為止。sql語句為：dbcc traceon(3502) 。
三、結尾
今天主要就是介紹了插入語句的執行過程，內容不多。你從這個過程中你會發現SQLServer真的很智能。比如這里的預寫日志來保護數據，延遲將數據寫入磁盤、預測SQL執行情況、監控負載調整內存等等。設計的都是那么巧妙，大家可以想想如果我們在設計自己的軟件時是否可以參考和借鑒呢?
今天分析就到此結束，文中如有描述不當的地方，歡迎指出。共同進步才是硬道理。
原文鏈接：http://www.cnblogs.com/yueyue_jwfm/archive/2011/06/30/2095006.html
【編輯推薦】
