這篇文章通過安全性，用法，并發處理等方便詳細分析了Mysql事務和數據的一致性處理問題，以下就是全部內容：
在工作中，我們經常會遇到這樣的問題，需要更新庫存，當我們查詢到可用的庫存準備修改時，這時，其他的用戶可能已經對這個庫存數據進行修改了，導致，我們查詢到的數據會有問題，下面我們就來看解決方法。
在MySQL的InnoDB中，預設的Tansaction isolation level 為REPEATABLE READ（可重讀）
如果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 就可以這樣測試，代碼如下:
| 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 |
如此可以確保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 的說明，以免造成系統經常發生死鎖。
更高級用法
如果我們需要先查詢，后更新數據的話，最好可以這樣使用語句：
| UPDATE products SET quantity = '1' WHERE id=3 AND quantity > 0; |
這樣，可以不用添加事物就可處理。
新聞熱點
疑難解答
