在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 下去了。因此必須透過的事務機制來確保讀取及提交的資料都是正確的。

於是我們在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;

樂觀所和悲觀鎖策略
悲觀鎖：在讀取資料時鎖住那幾行，其他對這幾行的更新需要等到悲觀鎖結束時才能繼續 。
樂觀所：讀取資料時不鎖，更新時檢查是否資料已經被更新過，如果是則取消當前更新，一般在悲觀鎖的等待時間過長而不能接受時我們才會選擇樂觀鎖。