為什么我也要說SQL Server的并行:
這幾天園子里寫關(guān)于SQL Server并行的文章很多,不管怎么樣,都讓人對(duì)并行操作有了更深刻的認(rèn)識(shí)。
我想說的是:盡管并行操作可能(并不是一定)存在這樣或者那樣的問題,但是我們不能否認(rèn)并行,仍然要利用好并行。
但是,實(shí)際開發(fā)中,某些SQL語句的寫法會(huì)導(dǎo)致用不到并行,從而影響到SQL的執(zhí)行效率
所以,本文要表達(dá)的是:我們要利用好并行,不要讓一些SQL的寫法問題“抑制”了并行,讓我們享受不了并行帶來的快感
關(guān)于SQL Server的并行:
所謂的并行,指SQL Server對(duì)于那些執(zhí)行代價(jià)相對(duì)較大(這個(gè)相對(duì)跟你的設(shè)置有關(guān))的SQL時(shí),如果數(shù)據(jù)庫服務(wù)器存在多顆CPU,SQL Server查詢引擎會(huì)采用并行的方式,也即采用多顆CPU參與整個(gè)運(yùn)算過程,每顆CPU“分擔(dān)”一部分計(jì)算任務(wù),最后匯總合并各個(gè)CPU的計(jì)算的一種行為有時(shí)候,不當(dāng)?shù)牟⑿胁樵儾坏粫?huì)加快查詢的速度,想反會(huì)拖慢查詢的效率,如果采用不當(dāng)?shù)牟⑿胁僮鳎踔習(xí)绊懙秸麄€(gè)服務(wù)器的穩(wěn)定性。
所以SQL Server 究竟在多大代價(jià)下啟用并行,是由配置的,這個(gè)配置可根據(jù)具體的情況做修改,有人說這個(gè)值的單位是“秒”,貌似沒見過權(quán)威的資料說過到底單位是什么,這里暫不追究
有清楚這個(gè)閾值單位的園友情不惜賜教,謝了
盡管并行操作可能存在這樣活著那樣的問題,但是我們不能因噎廢食,利用好并行,往往總是利大于弊。
但是并不是所有的執(zhí)行代價(jià)較大SQL都能用到并行操作,實(shí)際開發(fā)中,有一些SQL的寫法會(huì)抑制到并行操作,結(jié)果,導(dǎo)致整個(gè)SQL語句(存儲(chǔ)過程)的效率上不去。
下面來舉例說明。
并行查詢是如何變成了串行的:
如下是一個(gè)非常簡(jiǎn)單的查詢操作,這些寫法下,默認(rèn)情況下開啟了并行,可以看到,一共開啟了8個(gè)線程來對(duì)SQL語句做計(jì)算。
當(dāng)然這SQL的執(zhí)行效率還算不錯(cuò),CPU時(shí)間是622毫秒,執(zhí)行總時(shí)間是130毫秒,
這里不要弄混淆了,CPU時(shí)間的633毫秒,是8個(gè)CPU一共消耗的CPU時(shí)間,大于總的執(zhí)行130毫秒很正常的
下面創(chuàng)建一個(gè)非常簡(jiǎn)單的函數(shù),
CREATE function [dbo].[fn_justFunction](@p_date date)
returns date
as
begin
return @p_date
end
這個(gè)函數(shù)并沒有什么實(shí)際意義,執(zhí)行也非常簡(jiǎn)單,傳入一個(gè)時(shí)間,返回這個(gè)時(shí)間,
當(dāng)然這里只是為了下面的操作演示,你完全可以說我蛋疼,我只是為了演示并行被抑制的現(xiàn)象
翻翻你的SQL代碼,有沒有類似這種寫法?
然后我們這么寫這個(gè)查詢,就是在查詢條件上這么處理CreateDate>dbo.fn_justFunction('2015-1-1')(注意不是表的列,而是函數(shù)作用在查詢條件上),注意這個(gè)函數(shù)并不影響任何查詢結(jié)果,傳入的2015-1-1,返回位依舊是2015-1-1,但是這么一變化,并行就變成串行的了,SQL執(zhí)行期間只有一個(gè)CPU飚了起來,使用了到達(dá)80%左右,,與此同時(shí)其他CPU跟沒事人一樣,也不上來幫忙,還是很閑還記得上面并行操作方式執(zhí)行時(shí)間是多少么?130毫秒,現(xiàn)在粗看起來是多少,這里是4S,也就是4000毫秒了。差了多少倍,我數(shù)學(xué)不好算不出來
可以看到,并行操作和串行操作的效率差別還是很大的,對(duì)于CPU的利用也不充分(當(dāng)然我不是強(qiáng)調(diào)一定要用滿所有的CPU才算合理)
再次強(qiáng)調(diào)一點(diǎn),這里并不是在表的字段上加函數(shù)抑制了索引什么的,純粹的影響到的是并行操作。
當(dāng)然,抑制并行的寫法不單單是在查詢條件在使用函數(shù),實(shí)際開發(fā)中,影響會(huì)更大,
因?yàn)閷?shí)際業(yè)務(wù)中數(shù)據(jù)有可能會(huì)更大,SQL也可能更加復(fù)雜,這種情況可能更加難以甄別。
比如連接條件上,如下,連接條件上使用函數(shù)導(dǎo)致無法使用并行的情況,也是實(shí)際開發(fā)中遇到的
select * from TableA a inner join TableB b on a.id=b.id and a.Column=dbo.function(@Variable) where ***
當(dāng)然抑制到并行操作的不單單只有這兩種寫法,還有可能潛在其他類似的寫法也會(huì)影響到并行查詢。
這就要求我們?cè)趯慡QL的時(shí)候,不但要注意不能再字段上使用函數(shù)(無法使用該字段上的索引),同樣,查詢條件上也盡可能不要使用函數(shù),有可能影響到并行操作。
如果處理并行操作被抑制的情況:
如果要解決類似這些個(gè)問題,該怎么辦?其實(shí)也很簡(jiǎn)單,建議查詢條件通過函數(shù)運(yùn)算之后賦值給一個(gè)變量,用變量去作為查詢條件進(jìn)行查詢。
再次開始了愉快的并行,享受并行帶來的快感。
對(duì)于連接條件上的函數(shù)處理也類似,將結(jié)果計(jì)算出來之后,保存在一個(gè)變量中,把變量寫在連接條件中,
當(dāng)然可能有其他辦法,我暫時(shí)還沒有想到。
總結(jié):
本文通過一個(gè)簡(jiǎn)單的例子演示了并行操作被抑制的現(xiàn)象,說明了并行和串行在執(zhí)行一個(gè)代價(jià)較大的SQL上的性能的巨大的差別
其中提到的查詢方式是查詢條件上因?yàn)楹瘮?shù)的原因抑制了并行,完全區(qū)別于在查詢列上使用函數(shù)抑制索引的情況。
并行查詢可以充分調(diào)動(dòng)CPU資源,以高效的方式完成查詢,合理的利用并行會(huì)很大程度上提高SQL的執(zhí)行效率。
為了利用好并行,在寫SQL的時(shí)候,一定要注意,防止并行操作遭到抑制,給性能帶來影響.
SQL優(yōu)化是一個(gè)艱難而又反復(fù)的過程,即便如此,也樂在其中。
面對(duì)繁復(fù)SQL,不但要有過硬的技術(shù),也要有足夠的耐心,才能看清事物的本質(zhì)。
對(duì)并行的理解還不夠充分,有不對(duì)的地方希望各位看官指出,謝謝。
以上所述是小編給大家介紹的SQL Server并行操作優(yōu)化避免并行操作被抑制而影響SQL的執(zhí)行效率,希望對(duì)大家有所幫助,如果大家有任何疑問請(qǐng)給我留言,小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)腳本之家網(wǎng)站的支持!
您可能感興趣的文章:- 人工智能自動(dòng)sql優(yōu)化工具--SQLTuning for SQL Server
- sql語句優(yōu)化之SQL Server(詳細(xì)整理)
- SQL Server中的SQL語句優(yōu)化與效率問題
- SQL Server優(yōu)化50法匯總
- SQL Server游標(biāo)的使用/關(guān)閉/釋放/優(yōu)化小結(jié)
- 優(yōu)化 SQL Server 索引的小技巧
- SqlServer 索引自動(dòng)優(yōu)化工具