[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 同一個表單時很容易造成 Dead Lock 。

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

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

不安全的做法:

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

為什麼不安全呢?
少量的狀況下或許不會有問題,但是大量的資料存取「鐵定」會出問題。

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

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

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

SET AUTOCOMMIT=0;
BEGIN WORK;
SELECT quantity FROM products WHERE id=3 FOR UPDATE;
===========================================
此時 products 資料中 id=3 的資料被鎖住(註3),其它交易必須等待此次交易
送交後才能執行 SELECT * FROM products WHERE id=3 FOR UPDATE (註2)
如此可以確保 quantity 在別的交易讀到的數字是正確的。

===========================================
UPDATE products SET quantity = ‘1’ WHERE id=3 ;
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 的說明,以免造成系統經常發生 Deadlock。

143 comments On [MySQL] 使用 SELECT … FOR UPDATE 做交易寫入前的確認

Comments are closed.

Site Footer

Sliding Sidebar