MySQL悲觀鎖和樂觀鎖

引言：之所以叫做悲觀鎖，是因為這是一種對資料的修改抱有悲觀態度的併發控制方式。我們一般認為資料被併發修改的概率比較大，所以需要在修改之前先加鎖。

【例子】

//0.開始事務
begin; 
//1.查詢出商品庫存資訊
select quantity from items where id=1 for update;
//2.修改商品庫存為2
update items set quantity=2 where id = 1;
//3.提交事務
commit;

以上，在對id = 1的記錄修改前，先通過for update的方式進行加鎖，然後再進行修改。這就是比較典型的悲觀鎖策略。

如果以上修改庫存的**發生併發，同一時間只有乙個執行緒可以開啟事務並獲得id=1的鎖，其它的事務必須等本次事務提交之後才能執行。這樣我們可以保證當前的資料不會被其它事務修改。

引言：相對於悲觀鎖，在對資料庫進行處理的時候，樂觀鎖並不會使用資料庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄資料版本。

【例子】

//查詢出商品庫存資訊，quantity = 3
select quantity from items where id=1
//修改商品庫存為2
update items set quantity=2 where id=1 and quantity = 3;

以上，我們在更新之前，先查詢一下庫存表中當前庫存數（quantity），然後在做update的時候，以庫存數作為乙個修改條件。當我們提交更新的時候，判斷資料庫表對應記錄的當前庫存數與第一次取出來的庫存數進行比對，如果資料庫表當前庫存數與第一次取出來的庫存數相等，則予以更新，否則認為是過期資料。

但是以上更新語句存在乙個比較重要的問題，即aba問題。

比如說乙個執行緒1從資料庫中取出庫存數3，這時候另乙個執行緒2也從資料庫中庫存數3，並且執行緒2進行了一些操作將庫存數變成了2，緊接著又將庫存數變成3，這時候執行緒1進行cas操作發現資料庫中仍然是3，然後執行緒1操作成功。儘管執行緒1的cas操作成功，但是不代表這個過程就是沒有問題的。

有乙個比較好的辦法可以解決aba問題，那就是通過乙個單獨的可以順序遞增的version欄位。

【優化1】

//查詢出商品資訊，version = 1
select version from items where id=1
//修改商品庫存為2
update items set quantity=2,version = 3 where id=1 and version = 2;

以上sql其實還是有一定的問題的，就是一旦高併發的時候，就只有乙個執行緒可以修改成功，那麼就會存在大量的失敗。

【優化2】

//修改商品庫存
update item 
set quantity=quantity - 1 
where id = 1 and quantity - 1 > 0

以上sql語句中，如果使用者下單數為1，則通過quantity - 1 > 0的方式進行樂觀鎖控制。

以上update語句，在執行過程中，會在一次原子操作中自己查詢一遍quantity的值，並將其扣減掉1。

MySQL悲觀鎖和樂觀鎖

mysql悲觀鎖和樂觀鎖

悲觀鎖和樂觀鎖

悲觀鎖和樂觀鎖

相關推薦