假如兩個線程同時修改數據庫同一條記錄，就會導致后一條記錄覆蓋前一條，從而引發一些問題。

例如：

　　一個售票系統有一個余票數，客戶端每調用一次出票方法，余票數就減一。

情景： 

　　總共300張票，假設兩個售票點，恰好在同一時間出票，它們做的操作都是先查詢余票數，然后減一。

一般的sql語句：

　　

1
2
3
4
5
6
7
8
9
declare @count as int
 
begin tran
    select @count=count from ttt
    WAITFOR DELAY '00:00:05' --模擬并發，故意延遲5秒
    update ttt set count=@count-1
commit TRAN
 
SELECT * FROM ttt
　　

　　問題就在于，同一時間獲取的余票都為300，每個售票點都做了一次更新為299的操作，導致余票少了1，而實際出了兩張票。

　　打開兩個查詢窗口，分別快速運行以上代碼即可看到效果。

 

定義解釋：

　　悲觀鎖：相信并發是絕大部分的，并且每一個線程都必須要達到目的的。

　　樂觀鎖：相信并發是極少數的，假設運氣不好遇到了，就放棄并返回信息告訴它再次嘗試。因為它是極少數發生的。

 

悲觀鎖解決方案：

　　

1
2
3
4
5
6
7
declare @count as int
 
begin tran
    select @count=count from tb WITH(UPDLOCK)
　　 WAITFOR DELAY '00:00:05' --模擬并發，故意延遲5秒
    update tb set count=@count-1
commit tran
　　

　　在查詢的時候加了一個更新鎖，保證自查詢起直到事務結束不會被其他事務讀取修改，避免產生臟數據。

　　從而可以解決上述問題。

 

樂觀鎖解決方案：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
--首先給表加一列timestamp
 
ALTER TABLE ttt ADD timesFlag TIMESTAMP NOT null
 
然后更新時判斷這個值是否被修改
declare @count as int
DECLARE @flag AS TIMESTAMP
DECLARE @rowCount AS int
begin tran
    select @count=COUNT,@flag=timesflag from ttt
    WAITFOR DELAY '00:00:05'
    update ttt set count=@count-1 WHERE timesflag=@flag --這里加了條件
    SET @rowcount=@@ROWCOUNT  --獲取被修改的行數
commit TRAN
 
--對行數進行判斷即可
 
IF @rowCount=1
    PRINT '更新成功'
ELSE
    PRINT '更新失敗'
　　這便是樂觀鎖的解決方案，可以解決并發帶來的數據錯誤問題，但不保證每一次調用更新都成功，可能會返回'更新失敗'

 

悲觀鎖和樂觀鎖

　　悲觀鎖一定成功，但在并發量特別大的時候會造成很長堵塞甚至超時，僅適合小并發的情況。

　　樂觀鎖不一定每次都修改成功，但能充分利用系統的并發處理機制，在大并發量的時候效率要高很多。