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。代碼以下:

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

爲何不安全呢?

少許的情況下或許不會有問題，可是大量的數據存取「鐵定」會出問題。若是咱們須要在quantity>0 的狀況下才能扣庫存，假設程序在第一行SELECT 讀到的quantity 是2 ，看起來數字沒有錯，但 是當MySQL 正準備要UPDATE 的時候，可能已經有人把庫存扣成0 了，可是程序卻渾然不知，將錯就錯的UPDATE 下去了。所以必須透過的事務機制來確保讀取及提交的數據都是正確的。

1. 因而咱們在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 的說明，以避免形成系統常常發生死鎖。

MySQL SELECT ... FOR UPDATE 的Row Lock 與Table Lock

上面介紹過SELECT ... FOR UPDATE 的用法，不過鎖定(Lock)的數據是判別就得要注意一下了。因爲InnoDB 預設是Row-Level Lock，因此只有「明確」的指定主鍵，MySQL 纔會執行Row lock (只鎖住被選取的數據) ，不然MySQL 將會執行Table Lock (將整個數據表單給鎖住)。

舉個例子:

假設有個表單products ，裏面有id 跟name 二個欄位，id 是主鍵。 例1: (明確指定主鍵，而且有此數據，row lock) SELECT * FROM products WHERE id='3' FOR UPDATE; 例2: (明確指定主鍵，若查無此數據，無lock) SELECT * FROM products WHERE id='-1' FOR UPDATE; 例2: (無主鍵，table lock) SELECT * FROM products WHERE name='Mouse' FOR UPDATE; 例3: (主鍵不明確，table lock)

SELECT * FROM products WHERE id<>'3' FOR UPDATE;

例4: (主鍵不明確，table lock) SELECT * FROM products WHERE id LIKE '3' FOR UPDATE;

樂觀所和悲觀鎖策略

悲觀鎖：在讀取數據時鎖住那幾行，其餘對這幾行的更新須要等到悲觀鎖結束時才能繼續 。 樂觀所：讀取數據時不鎖，更新時檢查是否數據已經被更新過，若是是則取消當前更新，通常在悲觀鎖的等待時間過長而不能接受時咱們纔會選擇樂觀鎖。