為什么我也要說SQL Server的并行：

這幾天園子里寫關(guān)于SQL Server并行的文章很多，不管怎么樣，都讓人對并行操作有了更深刻的認識。

我想說的是：盡管并行操作可能（并不是一定）存在這樣或者那樣的問題，但是我們不能否認并行，仍然要利用好并行。

但是，實際開發(fā)中，某些SQL語句的寫法會導(dǎo)致用不到并行，從而影響到SQL的執(zhí)行效率

所以，本文要表達的是：我們要利用好并行，不要讓一些SQL的寫法問題“抑制”了并行，讓我們享受不了并行帶來的快感

關(guān)于SQL Server的并行：

所謂的并行，指SQL Server對于那些執(zhí)行代價相對較大（這個相對跟你的設(shè)置有關(guān)）的SQL時，如果數(shù)據(jù)庫服務(wù)器存在多顆CPU，SQL Server查詢引擎會采用并行的方式，也即采用多顆CPU參與整個運算過程，每顆CPU“分擔(dān)”一部分計算任務(wù)，最后匯總合并各個CPU的計算的一種行為有時候，不當(dāng)?shù)牟⑿胁樵儾坏粫涌觳樵兊乃俣龋敕磿下樵兊男剩绻捎貌划?dāng)?shù)牟⑿胁僮鳎踔習(xí)绊懙秸麄€服務(wù)器的穩(wěn)定性。

所以SQL Server 究竟在多大代價下啟用并行，是由配置的，這個配置可根據(jù)具體的情況做修改，有人說這個值的單位是“秒”，貌似沒見過權(quán)威的資料說過到底單位是什么，這里暫不追究

有清楚這個閾值單位的園友情不惜賜教，謝了

盡管并行操作可能存在這樣活著那樣的問題，但是我們不能因噎廢食，利用好并行，往往總是利大于弊。

但是并不是所有的執(zhí)行代價較大SQL都能用到并行操作，實際開發(fā)中，有一些SQL的寫法會抑制到并行操作，結(jié)果，導(dǎo)致整個SQL語句（存儲過程）的效率上不去。

下面來舉例說明。

并行查詢是如何變成了串行的：

　　如下是一個非常簡單的查詢操作，這些寫法下，默認情況下開啟了并行，可以看到，一共開啟了8個線程來對SQL語句做計算。

　　當(dāng)然這SQL的執(zhí)行效率還算不錯，CPU時間是622毫秒，執(zhí)行總時間是130毫秒，

　　這里不要弄混淆了，CPU時間的633毫秒，是8個CPU一共消耗的CPU時間，大于總的執(zhí)行130毫秒很正常的

　　下面創(chuàng)建一個非常簡單的函數(shù)，

CREATE function [dbo].[fn_justFunction](@p_date date)
returns date
as
begin
return @p_date
end

　　這個函數(shù)并沒有什么實際意義，執(zhí)行也非常簡單，傳入一個時間，返回這個時間，

　　當(dāng)然這里只是為了下面的操作演示，你完全可以說我蛋疼，我只是為了演示并行被抑制的現(xiàn)象

　　翻翻你的SQL代碼，有沒有類似這種寫法？

　　然后我們這么寫這個查詢，就是在查詢條件上這么處理CreateDate>dbo.fn_justFunction('2015-1-1')（注意不是表的列，而是函數(shù)作用在查詢條件上），注意這個函數(shù)并不影響任何查詢結(jié)果，傳入的2015-1-1，返回位依舊是2015-1-1，但是這么一變化，并行就變成串行的了，SQL執(zhí)行期間只有一個CPU飚了起來，使用了到達80%左右，，與此同時其他CPU跟沒事人一樣，也不上來幫忙，還是很閑還記得上面并行操作方式執(zhí)行時間是多少么？130毫秒，現(xiàn)在粗看起來是多少，這里是4S,也就是4000毫秒了。差了多少倍，我數(shù)學(xué)不好算不出來

　　可以看到，并行操作和串行操作的效率差別還是很大的，對于CPU的利用也不充分（當(dāng)然我不是強調(diào)一定要用滿所有的CPU才算合理）

　　再次強調(diào)一點，這里并不是在表的字段上加函數(shù)抑制了索引什么的，純粹的影響到的是并行操作。

　　當(dāng)然，抑制并行的寫法不單單是在查詢條件在使用函數(shù)，實際開發(fā)中，影響會更大，

　　因為實際業(yè)務(wù)中數(shù)據(jù)有可能會更大，SQL也可能更加復(fù)雜，這種情況可能更加難以甄別。

　　比如連接條件上，如下，連接條件上使用函數(shù)導(dǎo)致無法使用并行的情況，也是實際開發(fā)中遇到的

select * from TableA a inner join TableB b on a.id=b.id and a.Column=dbo.function(@Variable) where ***

　　當(dāng)然抑制到并行操作的不單單只有這兩種寫法，還有可能潛在其他類似的寫法也會影響到并行查詢。

　　這就要求我們在寫SQL的時候，不但要注意不能再字段上使用函數(shù)（無法使用該字段上的索引），同樣，查詢條件上也盡可能不要使用函數(shù)，有可能影響到并行操作。

如果處理并行操作被抑制的情況：

　　如果要解決類似這些個問題，該怎么辦？其實也很簡單，建議查詢條件通過函數(shù)運算之后賦值給一個變量，用變量去作為查詢條件進行查詢。

　　再次開始了愉快的并行，享受并行帶來的快感。

　　對于連接條件上的函數(shù)處理也類似，將結(jié)果計算出來之后，保存在一個變量中，把變量寫在連接條件中，

　　當(dāng)然可能有其他辦法，我暫時還沒有想到。

總結(jié)：

　　本文通過一個簡單的例子演示了并行操作被抑制的現(xiàn)象，說明了并行和串行在執(zhí)行一個代價較大的SQL上的性能的巨大的差別

　　其中提到的查詢方式是查詢條件上因為函數(shù)的原因抑制了并行，完全區(qū)別于在查詢列上使用函數(shù)抑制索引的情況。

　　并行查詢可以充分調(diào)動CPU資源，以高效的方式完成查詢，合理的利用并行會很大程度上提高SQL的執(zhí)行效率。

　　為了利用好并行，在寫SQL的時候，一定要注意，防止并行操作遭到抑制，給性能帶來影響.

　　SQL優(yōu)化是一個艱難而又反復(fù)的過程，即便如此，也樂在其中。

　　面對繁復(fù)SQL，不但要有過硬的技術(shù)，也要有足夠的耐心，才能看清事物的本質(zhì)。

　　對并行的理解還不夠充分，有不對的地方希望各位看官指出，謝謝。

以上所述是小編給大家介紹的SQL Server并行操作優(yōu)化避免并行操作被抑制而影響SQL的執(zhí)行效率，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復(fù)大家的。在此也非常感謝大家對腳本之家網(wǎng)站的支持！