Mysql高併發加鎖事務處理

MySQL 使用SELECT … FOR UPDATE 做事務寫入前的確認

以MySQL 的InnoDB 為例，預設的Tansaction isolation level 為REPEATABLE READ，在SELECT 的讀取鎖定主要分為兩種方式：

SELECT … LOCK IN SHARE MODE
SELECT … FOR UPDATE

這兩種方式在交易(Transaction) 進行當中SELECT 到同一個資料表時，都必須等待其它事務資料被提交(Commit)後才會執行。而主要的差異在於LOCK IN SHARE MODE 在有一方事務要Update 同一個表單時很容易造成死鎖 。

簡單的說，如果SELECT 後面若要UPDATE 同一個表單，最好使用 SELECT … UPDATE。

舉個例子：假設商品表單products 內有一個存放商品數量的quantity ，在訂單成立之前必須先確定quantity 商品數量是否足夠(quantity>0) ，然後才把數量更新為1。

不安全的做法：

1    SELECT quantity FROM products WHERE id=3;    
1    UPDATE products SET quantity = 1 WHERE id=3;

   

為什麼不安全呢？

少量的狀況下或許不會有問題，但是大量的資料存取「鐵定」會出問題。

如果我們需要在quantity>0 的情況下才能扣庫存，假設程式在第一行SELECT 讀到的quantity 是2 ，看起來數字沒有錯，但是當MySQL 正準備要UPDATE 的時候，可能已經有人把庫存扣成0 了，但是程式卻渾然不知，將錯就錯的UPDATE 下去了。

因此必須透過的事務機制來確保讀取及提交的資料都是正確的。

於是我們在MySQL 就可以這樣測試：(註1)

1    SET AUTOCOMMIT=0;    
2    BEGIN WORK;    
3    SELECT quantity FROM products WHERE id=3 FOR UPDATE;

 

此時products 資料中id=3 的資料被鎖定(註3)，其它事務必須等待此次事務提交後才能執行SELECT * FROM products WHERE id=3 FOR UPDATE (註2)如此可以確保quantity 在別的事務讀到的數字是正確的。

1    UPDATE products SET quantity = '1' WHERE id=3 ;    
2    COMMIT WORK;

提交(Commit)寫入資料庫，products 解鎖。

註1：BEGIN/COMMIT 為事務的起始及結束點，可使用二個以上的MySQL Command 視窗來交互觀察鎖定的狀況。

註2：在事務進行當中，只有SELECT … FOR UPDATE 或LOCK IN SHARE MODE 同一筆資料時會等待其它事務結束後才執行，一般SELECT … 則不受此影響。

註3：由於InnoDB 預設為Row-level Lock，資料列的鎖定可參考這篇。

註4：InnoDB 表單盡量不要使用LOCK TABLES 指令，若情非得已要使用，請先看官方對於InnoDB 使用LOCK TABLES 的說明，以免造成系統經常發生死鎖。

以上就是Mysql高併發加鎖事務處理的內容，更多相關內容請關注PHP中文網（www.php.cn）！