您好,登錄后才能下訂單哦!
今天就跟大家聊聊有關(guān)sql server 中編譯與重編譯的區(qū)別是什么,可能很多人都不太了解,為了讓大家更加了解,小編給大家總結(jié)了以下內(nèi)容,希望大家根據(jù)這篇文章可以有所收獲。
執(zhí)行計(jì)劃重用的利弊
執(zhí)行計(jì)劃的好壞當(dāng)然決定了語句最終的執(zhí)行速度。對于同樣的一條語句,使用好的執(zhí)行計(jì)劃可能會(huì)比差的要快幾百倍,甚至上千倍。
所以從這一個(gè)角度來講,每運(yùn)行一條語句,都把他先編譯一遍當(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ì)劃有哪些(請別在生產(chǎn)服務(wù)器上直接運(yùn)行因?yàn)樯厦嫱旋嫶蟮木彺?。
SELECT * FROM sys.[syscacheobjects]
重編譯的發(fā)生場景
但是有些時(shí)候,SQLSERVER為了確保返回正確的值,或者有性能上的顧慮,有意不重用緩存在內(nèi)存里的執(zhí)行計(jì)劃,而現(xiàn)場編譯一份。
這種行為,被稱為重編譯(recompile)。下面是比較常見的會(huì)發(fā)生重編譯的情形:
1、當(dāng)指令或者批處理所涉及的任何一個(gè)對象(表格或者視圖)發(fā)生了架構(gòu)(schema)變化
例如,在表或者視圖上添加或刪除了一個(gè)字段,添加或者刪除了一個(gè)索引,在表上添加或者刪除了一個(gè)約束條件(constraints)等。
定義發(fā)生了變化,原來的執(zhí)行計(jì)劃就不一定正確了,當(dāng)然要重編譯
2、運(yùn)行過sp_recompile
當(dāng)用戶在某個(gè)存儲(chǔ)過程或者觸發(fā)器上運(yùn)行過sp_recompile后,下一次運(yùn)行他們就會(huì)發(fā)生一次重編譯。
如果用戶在某個(gè)表或者視圖上運(yùn)行了sp_recompile,那么所有引用到這張表(或者視圖)的存儲(chǔ)過程在下一次運(yùn)行前,都要做重編譯
3、有些動(dòng)作會(huì)清除內(nèi)存里的所有執(zhí)行計(jì)劃,迫使大家都要做重編譯
例如,下列動(dòng)作會(huì)清除整個(gè)SQLSERVER服務(wù)器緩存的所有執(zhí)行計(jì)劃:
(1)Detach一個(gè)數(shù)據(jù)庫
(2)對數(shù)據(jù)庫做了升級,在新的服務(wù)器上,會(huì)發(fā)生執(zhí)行計(jì)劃清空
(3)運(yùn)行了DBCC freeproccache
(4)運(yùn)行了reconfigure語句
(5)運(yùn)行了alter database..collate語句修改了某個(gè)數(shù)據(jù)庫的字符集(collation)
下列動(dòng)作會(huì)清除SQLSERVER服務(wù)器緩存的某個(gè)數(shù)據(jù)庫的執(zhí)行計(jì)劃:
DBCC FLUSHPROCINDB
清除SQL Server 2000服務(wù)器內(nèi)存中的某個(gè)數(shù)據(jù)庫的存儲(chǔ)過程緩存內(nèi)容
1 DECLARE @a INT
2 SELECT @a=DB_ID('gposdb')
3 DBCC flushprocindb(@a)
ALTER DATABASE ...MODIFY NAME語句
ALTER DATABASE ...SET ONLINE語句
ALTER DATABASE...SET OFFLINE語句
ALTER DATABASE...SET EMERGENCY語句
DROP DATABASE 語句
當(dāng)一個(gè)數(shù)據(jù)庫自動(dòng)關(guān)閉時(shí)
DBCC CHECKDB語句結(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ì)影響語句的執(zhí)行的行為,甚至帶來不同的結(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ì)對所涉及的語句都做重編譯
需要說明的是,在SQLSERVER里,執(zhí)行計(jì)劃重用并不一定是一件好事,而編譯/重編譯也不一定是一件壞事。
計(jì)劃重用可以幫助SQLSERVER節(jié)省編譯時(shí)間,對降低CPU使用率和減少阻塞都有好處,但是缺點(diǎn)是每次重用的計(jì)劃并不一定是最合適的計(jì)劃。參數(shù)嗅探parameter sniffing就是典型的計(jì)劃重用帶來的負(fù)效應(yīng)。編譯和重編譯當(dāng)然能給當(dāng)前運(yùn)行的語句帶來盡可能準(zhǔn)確執(zhí)行計(jì)劃,但是對于經(jīng)常運(yùn)行的語句,尤其是一些執(zhí)行速度比較快的語句,可能其編譯時(shí)間占最后總時(shí)間的相當(dāng)大比例。這對資源來講是一個(gè)很大的浪費(fèi)
看完上述內(nèi)容,你們對sql server 中編譯與重編譯的區(qū)別是什么有進(jìn)一步的了解嗎?如果還想了解更多知識或者相關(guān)內(nèi)容,請關(guān)注億速云行業(yè)資訊頻道,感謝大家的支持。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。