SQLSERVER編譯與重編譯

編譯的含義

當(dāng)SQLSERVER收到任何一個(gè)指令，包括查詢（query）、批處理（batch）、存儲(chǔ)過(guò)程、觸發(fā)器（trigger）

、預(yù)編譯指令（prepared statement）和動(dòng)態(tài)SQL語(yǔ)句（dynamic SQL Statement）要完成語(yǔ)法解釋、語(yǔ)句解釋，

然后再進(jìn)行“編譯（compile）”，生成能夠運(yùn)行的“執(zhí)行計(jì)劃（execution plan）”。在編譯的過(guò)程中，

SQLSERVER會(huì)根據(jù)所涉及的對(duì)象的架構(gòu)（schema）、統(tǒng)計(jì)信息以及指令的具體內(nèi)容，估算可能的執(zhí)行計(jì)劃，

以及他們的成本（cost），最后選擇一個(gè)SQLSERVER認(rèn)為成本最低的執(zhí)行計(jì)劃來(lái)執(zhí)行。執(zhí)行計(jì)劃生成之后，

SQLSERVER通常會(huì)把他們緩存在內(nèi)存里，術(shù)語(yǔ)統(tǒng)稱他們叫“plan cache”以后同樣的語(yǔ)句執(zhí)行，SQLSERVER就可以使用同樣的執(zhí)行計(jì)劃，而無(wú)須再做一次編譯。

這種行為叫“重用（reuse）或者叫重用執(zhí)行計(jì)劃”。但是有時(shí)候，哪怕是一模一樣的語(yǔ)句，SQL下次執(zhí)行還是要再做一次編譯。

這種行為叫“重編譯（recompile）”。執(zhí)行計(jì)劃的編譯和重編譯都是要消耗資源的。

如果執(zhí)行計(jì)劃能夠重用，那么SQLSERVER就不需要再執(zhí)行上面的過(guò)程，加快執(zhí)行指令的速度，很多語(yǔ)句調(diào)優(yōu)的文章里提到數(shù)據(jù)庫(kù)重用執(zhí)行計(jì)劃就是指這個(gè)意思

執(zhí)行計(jì)劃重用的利弊

執(zhí)行計(jì)劃的好壞當(dāng)然決定了語(yǔ)句最終的執(zhí)行速度。對(duì)于同樣的一條語(yǔ)句，使用好的執(zhí)行計(jì)劃可能會(huì)比差的要快幾百倍，甚至上千倍。

所以從這一個(gè)角度來(lái)講，每運(yùn)行一條語(yǔ)句，都把他先編譯一遍當(dāng)然是最好的。他能夠保證使用的執(zhí)行計(jì)劃是SQLSERVER能找到的最優(yōu)的。

但是SQLSERVER每秒鐘可能會(huì)運(yùn)行成百上千的指令。如果每個(gè)都編譯一遍，是資源的一種浪費(fèi)。所以SQLSERVER在這里也試圖尋找一個(gè)平衡點(diǎn)，

使用有限的compile/recompile，得到最好的整體性能

運(yùn)行下面的指令，就能夠看到SQLSERVER當(dāng)前緩存的執(zhí)行計(jì)劃有哪些（請(qǐng)別在生產(chǎn)服務(wù)器上直接運(yùn)行因?yàn)樯厦嫱旋嫶蟮木彺妫?/p>

1 SELECT * FROM sys.[syscacheobjects]

重編譯的發(fā)生場(chǎng)景

但是有些時(shí)候，SQLSERVER為了確保返回正確的值，或者有性能上的顧慮，有意不重用緩存在內(nèi)存里的執(zhí)行計(jì)劃，而現(xiàn)場(chǎng)編譯一份。

這種行為，被稱為重編譯（recompile）。下面是比較常見(jiàn)的會(huì)發(fā)生重編譯的情形：

1、當(dāng)指令或者批處理所涉及的任何一個(gè)對(duì)象（表格或者視圖）發(fā)生了架構(gòu)（schema）變化

例如，在表或者視圖上添加或刪除了一個(gè)字段，添加或者刪除了一個(gè)索引，在表上添加或者刪除了一個(gè)約束條件（constraints）等。

定義發(fā)生了變化，原來(lái)的執(zhí)行計(jì)劃就不一定正確了，當(dāng)然要重編譯

2、運(yùn)行過(guò)sp_recompile

當(dāng)用戶在某個(gè)存儲(chǔ)過(guò)程或者觸發(fā)器上運(yùn)行過(guò)sp_recompile后，下一次運(yùn)行他們就會(huì)發(fā)生一次重編譯。

如果用戶在某個(gè)表或者視圖上運(yùn)行了sp_recompile，那么所有引用到這張表（或者視圖）的存儲(chǔ)過(guò)程在下一次運(yùn)行前，都要做重編譯

3、有些動(dòng)作會(huì)清除內(nèi)存里的所有執(zhí)行計(jì)劃，迫使大家都要做重編譯

例如，下列動(dòng)作會(huì)清除整個(gè)SQLSERVER服務(wù)器緩存的所有執(zhí)行計(jì)劃：

(1)Detach一個(gè)數(shù)據(jù)庫(kù)

(2)對(duì)數(shù)據(jù)庫(kù)做了升級(jí)，在新的服務(wù)器上，會(huì)發(fā)生執(zhí)行計(jì)劃清空

(3)運(yùn)行了DBCC freeproccache

(4)運(yùn)行了reconfigure語(yǔ)句

(5)運(yùn)行了alter database..collate語(yǔ)句修改了某個(gè)數(shù)據(jù)庫(kù)的字符集（collation）

下列動(dòng)作會(huì)清除SQLSERVER服務(wù)器緩存的某個(gè)數(shù)據(jù)庫(kù)的執(zhí)行計(jì)劃：

DBCC FLUSHPROCINDB

清除SQL Server 2000服務(wù)器內(nèi)存中的某個(gè)數(shù)據(jù)庫(kù)的存儲(chǔ)過(guò)程緩存內(nèi)容

1 DECLARE @a INT
2 SELECT @a=DB_ID('gposdb')
3 DBCC flushprocindb(@a)

ALTER DATABASE ...MODIFY NAME語(yǔ)句

ALTER DATABASE ...SET ONLINE語(yǔ)句

ALTER DATABASE...SET OFFLINE語(yǔ)句

ALTER DATABASE...SET EMERGENCY語(yǔ)句

DROP DATABASE 語(yǔ)句

當(dāng)一個(gè)數(shù)據(jù)庫(kù)自動(dòng)關(guān)閉時(shí)

DBCC CHECKDB語(yǔ)句結(jié)束時(shí)

4、當(dāng)下面這些SET 開關(guān)值變化后，先前的那些執(zhí)行計(jì)劃都不能重用

ansi_null_dflt_off,

ansi_null_dflt_on,

ansi_nulls,

_ansi_padding

ansi_warnings,

arithabort,

concat_null_yields_null,

datefirst,dateformat,

forceplan,

language,

no_browsetable,

numeric_roundabort,

quoted_identifier

這是因?yàn)檫@些SET開關(guān)會(huì)影響語(yǔ)句的執(zhí)行的行為，甚至帶來(lái)不同的結(jié)果。他們發(fā)生變化了，SQLSERVER就要根據(jù)新的設(shè)置重做執(zhí)行計(jì)劃

5、當(dāng)表格或者視圖上的統(tǒng)計(jì)信息發(fā)生變化后

當(dāng)統(tǒng)計(jì)信息被手動(dòng)更新后，或者SQLSERVER發(fā)現(xiàn)某個(gè)統(tǒng)計(jì)信息需要自動(dòng)更新時(shí)，SQLSERVER會(huì)對(duì)所涉及的語(yǔ)句都做重編譯 

需要說(shuō)明的是，在SQLSERVER里，執(zhí)行計(jì)劃重用并不一定是一件好事，而編譯/重編譯也不一定是一件壞事。

計(jì)劃重用可以幫助SQLSERVER節(jié)省編譯時(shí)間，對(duì)降低CPU使用率和減少阻塞都有好處，但是缺點(diǎn)是每次重用的計(jì)劃并不一定是最合適的計(jì)劃。參數(shù)嗅探parameter sniffing就是典型的計(jì)劃重用帶來(lái)的負(fù)效應(yīng)。編譯和重編譯當(dāng)然能給當(dāng)前運(yùn)行的語(yǔ)句帶來(lái)盡可能準(zhǔn)確執(zhí)行計(jì)劃，但是對(duì)于經(jīng)常運(yùn)行的語(yǔ)句，尤其是一些執(zhí)行速度比較快的語(yǔ)句，可能其編譯時(shí)間占最后總時(shí)間的相當(dāng)大比例。這對(duì)資源來(lái)講是一個(gè)很大的浪費(fèi)

一般來(lái)說(shuō)，SQLSERVER能夠很好地在編譯與重編譯之間做平衡，大部分情況下沒(méi)什么問(wèn)題的。

感謝閱讀，希望能幫助到大家，謝謝大家對(duì)本站的支持！

最新評(píng)論