前言
本節我們來講講並發中最常見的情況存在即更新,在並發中若未存在行記錄則插入,此時未處理好極容易出現插入重復鍵情況,本文我們來介紹對並發中存在就更新行記錄的七種方案並且我們來綜合分析最合適的解決方案。
探討存在就更新七種方案
首先我們來創建測試表
IF OBJECT_ID('Test') IS NOT NULL DROP TABLE Test CREATE TABLE Test ( Id int, Name nchar(100), [Counter] int,primary key (Id), unique (Name) ); GO
解決方案一(開啟事務)
我們統一創建存儲過程通過來SQLQueryStress來測試並發情況,我們來看第一種情況。
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) BEGIN TRANSACTION IF EXISTS ( SELECT 1 FROM Test WHERE Id = @Id ) UPDATE Test SET [Counter] = [Counter] + 1 WHERE Id = @Id; ELSE INSERT Test ( Id, Name, [Counter] ) VALUES ( @Id, @Name, 1 ); COMMIT GO
同時開啟100個線程和200個線程出現插入重復鍵的幾率比較少還是存在。
解決方案二(降低隔離級別為最低隔離級別UNCOMMITED)
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED BEGIN TRANSACTION IF EXISTS ( SELECT 1 FROM Test WHERE Id = @Id ) UPDATE Test SET [Counter] = [Counter] + 1 WHERE Id = @Id; ELSE INSERT Test ( Id, Name, [Counter] ) VALUES ( @Id, @name, 1 ); COMMIT GO
此時問題依舊和解決方案一無異(如果降低級別為最低隔離級別,如果行記錄為空,前一事務如果未進行提交,當前事務也能讀取到該行記錄為空,如果當前事務插入進去並進行提交,此時前一事務再進行提交此時就會出現插入重復鍵問題)
解決方案三(提升隔離級別為最高級別SERIALIZABLE)
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRANSACTION IF EXISTS ( SELECT 1 FROM dbo.Test WHERE Id = @Id ) UPDATE dbo.Test SET [Counter] = [Counter] + 1 WHERE Id = @Id; ELSE INSERT dbo.Test ( Id, Name, [Counter] ) VALUES ( @Id, @Name, 1 ); COMMIT GO
在這種情況下更加糟糕,直接到會導致死鎖
此時將隔離級別提升為最高隔離級別會解決插入重復鍵問題,但是對於更新來獲取排它鎖而未提交,而此時另外一個進程進行查詢獲取共享鎖此時將造成進程間相互阻塞從而造成死鎖,所以從此知最高隔離級別有時候能夠解決並發問題但是也會帶來死鎖問題。
解決方案四(提升隔離級別+良好的鎖)
此時我們再來在添加最高隔離級別的基礎上增添更新鎖,如下:
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRANSACTION IF EXISTS ( SELECT 1 FROM dbo.Test WITH(UPDLOCK) WHERE Id = @Id ) UPDATE dbo.Test SET [Counter] = [Counter] + 1 WHERE Id = @Id; ELSE INSERT dbo.Test ( Id, Name, [Counter] ) VALUES ( @Id, @Name, 1 ); COMMIT GO
運行多次均未發現出現什么異常,通過查詢數據時使用更新鎖而非共享鎖,這樣的話一來可以讀取數據但不阻塞其他事務,二來還確保自上次讀取數據后數據未被更改,這樣就解決了死鎖問題。貌似這樣的方案是可行得,如果是高並發不知是否可行。
解決方案五(提升隔離級別為行版本控制SNAPSHOT)
ALTER DATABASE UpsertTestDatabase SET ALLOW_SNAPSHOT_ISOLATION ON ALTER DATABASE UpsertTestDatabase SET READ_COMMITTED_SNAPSHOT ON GO IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) BEGIN TRANSACTION IF EXISTS ( SELECT 1 FROM dbo.Test WHERE Id = @Id ) UPDATE dbo.Test SET [Counter] = [Counter] + 1 WHERE Id = @Id; ELSE INSERT dbo.Test ( Id, Name, [Counter] ) VALUES ( @Id, @Name, 1 ); COMMIT GO
上述解決方案也會出現插入重復鍵問題不可取。
解決方案六(提升隔離級別+表變量)
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) DECLARE @updated TABLE ( i INT ); SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; BEGIN TRANSACTION UPDATE Test SET [Counter] = [Counter] + 1 OUTPUT DELETED.Id INTO @updated WHERE Id = @Id; IF NOT EXISTS ( SELECT i FROM @updated ) INSERT INTO Test ( Id, Name, counter ) VALUES ( @Id, @Name, 1 ); COMMIT GO
經過多次認證也是零錯誤,貌似通過表變量形式實現可行。
解決方案七(提升隔離級別+Merge)
通過Merge關鍵來實現存在即更新否則則插入,同時我們應該注意設置隔離級別為 SERIALIZABLE 否則會出現插入重復鍵問題,代碼如下:
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) SET TRAN ISOLATION LEVEL SERIALIZABLE BEGIN TRANSACTION MERGE Test AS [target] USING ( SELECT @Id AS Id ) AS source ON source.Id = [target].Id WHEN MATCHED THEN UPDATE SET [Counter] = [target].[Counter] + 1 WHEN NOT MATCHED THEN INSERT ( Id, Name, [Counter] ) VALUES ( @Id, @Name, 1 ); COMMIT GO
多次認證無論是並發100個線程還是並發200個線程依然沒有異常信息。
總結
本節我們詳細討論了在並發中如何處理存在即更新,否則即插入問題的解決方案,目前來講以上三種方案可行。
解決方案一(最高隔離級別 + 更新鎖)
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) BEGIN TRANSACTION; UPDATE dbo.Test WITH ( UPDLOCK, HOLDLOCK ) SET [Counter] = [Counter] + 1 WHERE Id = @Id; IF ( @@ROWCOUNT = 0 ) BEGIN INSERT dbo.Test ( Id, Name, [Counter] ) VALUES ( @Id, @Name, 1 ); END COMMIT GO
解決方案二(最高隔離級別 + 表變量)
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) DECLARE @updated TABLE ( i INT ); SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; BEGIN TRANSACTION UPDATE Test SET [Counter] = [Counter] + 1 OUTPUT DELETED.id INTO @updated WHERE id = @id; IF NOT EXISTS ( SELECT i FROM @updated ) INSERT INTO Test ( Id, Name, counter ) VALUES ( @Id, @Name, 1 ); COMMIT GO
解決方案三(最高隔離級別 + Merge)
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) SET TRAN ISOLATION LEVEL SERIALIZABLE BEGIN TRANSACTION MERGE Test AS [target] USING ( SELECT @Id AS Id ) AS source ON source.Id = [target].Id WHEN MATCHED THEN UPDATE SET [Counter] = [target].[Counter] + 1 WHEN NOT MATCHED THEN INSERT ( Id, Name, [Counter] ) VALUES ( @Id, @Name, 1 ); COMMIT GO
暫時只能想到這三種解決方案,個人比較推薦方案一和方案三, 請問您有何高見,請留下您的評論若可行,我將進行后續補充。
2017-06-03更新
本博文的評論非常精彩,同時對於小菜的我又重新學習了下存在即更新反之則插入的解決方案。本文重新更新已經過了兩天,期間我是一直在看這方面的東西更加深入的理解有些基礎方面的東西還是說的太籠統並且是我自身不是很理解而導致,菜不可怕,可怕的是還不深入學習自認為自己的是對的,你說呢。
首先我們得理解UPDLOCK和HOLDLOCK鎖的作用是什么,HOLDLOCK類似於SERIALIZABLE隔離級別,對於共享鎖我們是可以讀,但是不能進行更新和刪除和插入直到當前並發事務完成,而UPDLOCK園中博文的解釋:是允許您讀取數據(不阻塞其它事務)並在以后更新數據,同時確保自從上次讀取數據后數據沒有被更改。當我們用它來讀取記錄時可以對取到的記錄加上更新鎖,從而加上鎖的記錄在其它的線程中是不能更改的只能等本線程的事務結束后才能更改。通俗易懂點說,它不會阻塞並發的查詢和插入操作,但是會阻塞更新或者刪除對於當前事務查詢出的數據,當查詢到該數據存在時則有更新鎖切換到排它鎖。所以對於上述結尾總結的三種解決方案,我們再來闡述下。
解決方案一(HOLDLOCK)
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) BEGIN TRANSACTION; UPDATE dbo.Test WITH ( HOLDLOCK ) SET [Counter] = [Counter] + 1 WHERE Id = @Id; IF ( @@ROWCOUNT = 0 ) BEGIN INSERT dbo.Test ( Id, Name, [Counter] ) VALUES ( @Id, @Name, 1 ); END COMMIT GO
如果我們未加上HOLDLOCK鎖提示,雖然UPDATE會獲取排它鎖,但是排它鎖不會持續到事務結束一直保持着所以會導致插入重復鍵的問題,當我們加上HOLDLOCK鎖提示上述也說到類似悲觀並發中的最高隔離級別,該鎖提示一直會持續到事務結束,當有並發請求過來時,若此時查詢到數據存在則會進行更新操作但是事務還未進行提交,此時其他請求將會也查到該行記錄存在,但是會被當前的事務更新操作鎖阻塞,若此時查詢到數據不存在時同理如此。
解決方案二(UPDLOCK + HOLDLOCK)
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) BEGIN TRANSACTION IF EXISTS ( SELECT 1 FROM dbo.Test WITH(UPDLOCK, HOLDLOCK) WHERE Id = @Id ) UPDATE dbo.Test SET [Counter] = [Counter] + 1 WHERE Id = @Id; ELSE INSERT dbo.Test ( Id, Name, [Counter] ) VALUES ( @Id, @Name, 1 ); COMMIT GO
對於上述查詢對比第一種解決方案我們加上了UPDLOCK更新鎖代替SELECT的共享鎖,目的是當所傳遞的變量Id所查詢的行記錄不存在時不會導致阻塞,讓其進行插入,也就是說不阻塞其他事務的插入並確保自上次以來行記錄未被修改過,對於HOLDLOCK為了確保一直到事務釋放鎖,從而達到我們的期望。總結起來一句話,如果查詢期間行記錄存在則鎖定的資源則查詢存在的行記錄上,如果查詢期間行記錄不存在,那么通過HOLDLOCK來獲取主鍵上的范圍鎖來防止在釋放鎖之前插入重復鍵,所以UPDLOCK為了解決並發更新不阻塞其他事務查詢,HOLDLOCK防止並發插入重復鍵。
解決方案三(SERIALIZABLE + Merge)
IF OBJECT_ID('TestPro') IS NOT NULL DROP PROCEDURE TestPro; GO CREATE PROCEDURE TestPro ( @Id INT ) AS DECLARE @Name NCHAR(100) = CAST(@Id AS NCHAR(100)) BEGIN TRANSACTION MERGE Test WITH(SERIALIZABLE ) AS [target] USING ( SELECT @Id AS Id ) AS source ON source.Id = [target].Id WHEN MATCHED THEN UPDATE SET [Counter] = [target].[Counter] + 1 WHEN NOT MATCHED THEN INSERT ( Id, Name, [Counter] ) VALUES ( @Id, @Name, 1 ); COMMIT GO
測試
UPDLOCK.UPDLOCK 的優點是允許您讀取數據(不阻塞其它事務)並在以后更新數據,同時確保自從上次讀取數據后數據沒有被更改。當我們用UPDLOCK來讀取記錄時可以對取到的記錄加上更新鎖,從而加上鎖的記錄在其它的線程中是不能更改的只能等本線程的事務結束后才能更改.
示例:
測試:
在另一個查詢里:
BEGIN TRANSACTION
SELECT * FROM myTable WITH (UPDLOCK) WHERE Id in (1,2,3)
waitfor delay '00:00:10'
update myTable set [Name]='ZZ' where Id in (1,2,3)
commit TRANSACTION
在另一個查詢里:
SELECT * FROM myTable WHERE Id in (1,2,3)
可以馬上查詢到數據。
但如果要更新數據,必須等其他更新鎖釋放后才能執行。
update myTable set [Name]='ZZ' where Id in (1,2,3)
這就說明,有時候需要控制某條記錄在我讀取后就不許再進行更新,那么我就可以將所有要處理當前記錄的查詢都加上更新鎖,以防止查詢后被其它事務修改.將事務的影響降低到最小