[MySQL] 使用 SELECT ... FOR UPDATE 做交易寫入前的確認

三月 4, 2006

以 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。