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）！
