寫事務日志：數據修改事務中唯一一個總是需要寫入磁盤的操作。并不是修改查詢語句的清單，而是修改操作發生之后數據頁面的具體變化。是由日志管理器完成。看到寫入磁盤，我們應該立刻聯想到性能問題，因為這個操作是總是寫入磁盤。如果一條語句的操作的數據很大的話，這個耗時是十分可怕的。

　　舉個例子：如果想知道這個差距，你可以在百萬或者千萬的表中執行以下兩條語句體會以下：truncate table Test以及delete from Test。當然嚴謹的同學會說truncate是針對區操作，delete是針對頁操作，truncate的鎖消耗也比delete的鎖消耗少。這些是會導致truncate比delete快的原因。但是這些原因不是主要原因，主要原因就是這里說的寫事務日志，delete是每次刪除一行，并在事務日志中為所刪除的每行記錄一項，而truncate是通過釋放存儲表數據所用的數據頁來刪除數據，并且只在事務日志中記錄頁的釋放。既然事務日志會影響性能，為什么還記錄呢？主要解決保護數據以及數據一致性的問題。

　　接收寫請求：一旦訪問方法接收到寫事務日志成功的確認信息，就會接收寫請求，將寫請求發送緩存區管理器。注意了，這里是把請求交給緩存區管理器，緩存區管理器只是操作緩存跟物理文件沒有任何關系。這里強調的目的是，如果沒有理解這里說的原理的話。你可能會為自己做了大量的插入操作，而數據文件的大小沒有任何變化而感到匪夷所思。訪問方法表面上起了請求傳遞的作用，其實它很智能，有一些比較復雜的算法來預測執行情況。

　　插入緩沖池：緩沖區管理器在內存中插入數據，插入成功后將確認結果發送給訪問方法，最終確認結果到達客戶端。

　　寫入數據文件：這個步驟可以由兩個組件任何一個完成。惰性寫入器線程定期檢查SQL Server空閑緩沖列表的大小，當這個值過低的時候，惰性寫入器會掃描整個數據緩存，將所有一段時間沒被使用的頁面老化。如果找到一段時間沒有被使用的臟頁，惰性寫入器則將其寫入磁盤并且刪除，然后將這個頁面的內存空間標記為空閑空間。惰性寫入器還會監測服務器上的空閑物理內存，如果內存很少它會將SQL Server的空閑緩沖列表釋放給Windows，在SQL Server負載很重時，它還會在服務器有空閑物理內存且已給SQL Server分配的內存還沒有達到我們配置的最大服務器內存（max server memory）時增加SQL Server的空閑緩沖列表以適應負載。

　　檢查點是檢查點線程創建的一個時間點，將保證臟頁都寫入磁盤，并且在頁面頭將緩存中的這個頁面標記為干凈的頁面，注意檢查點是不刪除臟頁的。至于檢查點的執行時間是要分幾種情況的：如果你配置了recovery interval（min），就以這個為準。如果沒有配置，并且這上一次檢查點結束后寫入的事務日志數據超過10MB，則大約每分鐘啟動一次。還比如，我們人為執行checkpoint執行，或者執行備份重啟命令都會觸發檢查點。拋開我們人為操作，這個具體時間確實無法確定，SQL Server有內部啟發算法控制這個值。不過我們可以開啟一個跟蹤標志3502能查看。這個跟蹤標志在錯誤日志中記錄了檢查點的開始與結束為止。sql語句為：dbcc traceon(3502) 。

　　三、結尾

　　今天主要就是介紹了插入語句的執行過程，內容不多。你從這個過程中你會發現SQL Server真的很智能。比如這里的預寫日志來保護數據，延遲將數據寫入磁盤、預測SQL執行情況、監控負載調整內存等等。設計的都是那么巧妙，大家可以想想如果我們在設計自己的軟件時是否可以參考和借鑒呢？

　　今天分析就到此結束，文中如有描述不當的地方，歡迎指出。共同進步才是硬道理。

　　相關文章：擦亮自己的眼睛去看SQLServer之簡單Select