SQL Server並行死鎖案例解析

本文轉載自查看原文 2015-10-10 12:45 1235 死鎖/ 並行查詢

並行執行作為提升查詢響應時間,提高用戶體驗的一種有效手段被大家所熟知,感興趣的朋友可以看我以前的博客SQL Server優化技巧之SQL Server中的"MapReduce", SQL Server優化器特性-位圖過濾(Bitmap),然而正如我一直強調的,任何事物均有利弊,重點在於抉擇.近日有朋友問我關於在今年7月份SQL Saturday中分享的並行執行中關於並行死鎖的內容,這里我就詳細解釋下我舉的實例中的並行死鎖.

並行死鎖我們可以理解為SQL Server的”BUG”,即按照並行方式執行時遭遇特定異常使得執行無法繼續.官方給的解決方式大多很簡單,改為串行就可以了.但其中還是有值得我們深究的地方以便我們更好的利用並行.

注:由於案例涉及的並行知識點較多,缺乏相關知識的同學可以先預覽一下我當時分享的PPT,如果有不清楚的地方也可以私信我. Inside Parallel Query

閑篇到此,上實例

生成測試數據

CREATE TABLE Numbers
(
    Number INT NOT NULL,
    CONSTRAINT PK_Numbers 
        PRIMARY KEY CLUSTERED (Number)
        WITH FILLFACTOR = 100
)

INSERT INTO Numbers
SELECT
    (a.Number * 256) + b.Number AS Number
FROM 
    (
        SELECT number
        FROM master..spt_values
        WHERE 
            type = 'P'
            AND number <= 255
    ) a (Number),
    (
        SELECT number
        FROM master..spt_values
        WHERE 
            type = 'P'
            AND number <= 255
    ) b (Number)

View Code

接下來我們執行如下語句,取30000下最大偶數,此時我將執行並行數maxdop隨意調整為奇數,3,5,7我的執行都可以迅速返回結果.

執行代碼

set statistics time on
select 
      maxN=max(num.number)
from dbo.numbers as num
where 
      num.number<30000
      and convert(integer,convert(varchar(max),num.number)) % 2=0
option
(
Maxdop 3,-----5,7
querytraceon 8649
);

View Code

但當我將並行數調整為偶數時,執行時間居然長達數秒…打開trace profiler跟蹤dead lock chain我們發現,當並行數為偶數時出現了死鎖.

如圖1-1,1-2,1-3

select 
      maxN=max(num.number)
from dbo.numbers as num
where 
      num.number<30000
      and convert(integer,convert(varchar(max),num.number)) % 2=0
option
(
Maxdop 4,-----2,6
querytraceon 8649
);