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