在 InnoDB 的行鎖中使用所謂的 next-key locking。這就意味著，除了索引記錄外，InnoDB 還可以鎖定該索引記錄前部“間隙” ('gap') 以阻塞其它用戶在索引記錄前部的直接插入。next-key lock 意思是鎖定一個索引記錄以及該記錄之前的間隙(gap)。gap lock 就是只鎖定某些索引記錄之前的間隙。

Consistent read

Consistent read 就是 InnoDB 使用它的多版本(multiversioning)方式提供給查詢一個數據庫在一個時間點的快照。查詢將會檢查那些在這個時間點之前提交的事務所做的改動，以及在時間點之后改變或未提交的事務? 與這個規則相例外的是查詢將檢查查詢自身發出的事務所做的改變。

如果以默認的 REPEATABLE READ 隔離級，那么所有在同一事務中的 consistent reads 只讀取同一個在事務中第一次讀所確定的快照。你可以通過提交當前事務并發出一個新的查詢以獲得新的數據快照。

Consistent read 在 InnoDB 處理 SELECT 中的默認模式是 READ COMMITTED 和 REPEATABLE READ 隔離級。Consistent read 對其所訪問的表不加任何鎖定，因而其它任何用戶均可以修改在 consistent read 被完成之前自由的修改這些表。

Locking reads

Consistent read (mysql默認) 未提交讀,允許臟讀，也就是可能讀取到其他會話中未提交事務修改的數據

方式:select .......

Consistent read 在某些情況下是不太方便的。 假設你希望在表 CHILD 中插入 一個新行，而這個子表已有一個父表 PARENT。

假設你使用 consistent read 了讀取表 PARENT 并查看子表中對應記錄。你真的能安全地在表 CHILD 中加入一個子行？不可能，因為在此期間可能有其它用戶刪除了表 PARENT 中的父行，而你并不知道它。

提交讀(Read Committed)只能讀取到已經提交的數據。Oracle等多數數據庫默認都是該級別

方式:??SELECT.....?LOCK IN SHARE MODE;? //會產生死鎖?共享訪問鎖?? //一般

在共享模式下執行讀取的意思就是讀取最新的現有資料，并在所讀取的行上設置一個共享模式的鎖定。如果最新的數據屬于其它用戶仍未提交的事務，那將不得不等到這個事務被提交。共享模式的可以防止其它用戶更新或刪除我們當前所讀取的行。當查詢獲得 Jones后，就可以安全地向子表 CHILD 中加入子行，然后提交事務。這個例子顯示如何在應用程序代碼中實現參照完整性。

另外一個例子： 在表 CHILD_CODES 有一個整型計數字段用于給在表 CHILD 中加入的每個子行賦于一個唯一的標識符。顯而易見地，用一個 consistent read 來讀取父表中的值并不是一個好的主意，因兩個用戶有可能會讀取出同一個計數值，當以同一個標識符插入兩個字行時將會產生一個重復鍵值(duplicate key)的錯誤。如果兩個用戶同時讀取了計數器，當嘗試更新計數器時，他們中的一個必將在死鎖中結束，所以在讀取時使用 LOCK IN SHARE MODE 也并不是一個好的解決辦法。

可重復讀(Repeated Read)：可重復讀。在同一個事務內的查詢都是事務開始時刻一致的，InnoDB默認級別。在SQL標準中，該隔離級別消除了不可重復讀，但是還存在幻象讀 (幻象讀。多鎖住一些沒用的行 下面有詳細)

SELECT ... FOR UPDATE??????? //安全最高

在這和情況下有兩種方法來實現讀取并增加計數器：(1) 首先更新計數器然后再讀取它；(2) 首先以一個 FOR UPDATE 方式鎖定后再讀取，然后再增加它：

SELECT COUNTER_FIELD FROM CHILD_CODES FOR UPDATE;

UPDATE CHILD_CODES SET COUNTER_FIELD = COUNTER_FIELD + 1;

SELECT ... FOR UPDATE

將讀取最新的現有數據，并在所讀取的行上設置排它的鎖定。

同樣在 SQL UPDATE 所訪問的行上也設置此鎖定。

Next-key locking: avoiding the phantom problem 在 InnoDB 的行級鎖定上使用一個稱作 next-key locking 算法。在 InnoDB 在搜索或掃描表的索引時將進行行鎖，它將在所訪問到的索引上設置共享或排它的鎖定。因而行鎖是更加精確地而又稱為索引記錄鎖定。 InnoDB 在索引記錄上設置的鎖同樣會影響索引記錄之前的“間隙(gap)”。如果一個用戶對索引記錄 R 加了一個共享或排它的鎖定，那其它用戶將不能在 R 之前立即插入新的記錄。這種間隙鎖定用于防止所謂的“phantom

problem”。假設需讀取和鎖定表 CHILD 中標識符大于 100 的子行，并更新所搜索到的記錄中某些字段。

SELECT * FROM CHILD WHERE ID > 100 FOR UPDATE;? 假設表 CHILD 中有一個索引字段 ID。我們的查詢將從 ID 大于100的第一條記錄開始掃描索引記錄。 現在，假設加在索引記錄上的鎖定不能阻止在間隙處的插入，一個新的子記錄將可能在事務處理中被插入到表中。

如果現在在事務中再次執行 SELECT * FROM CHILD WHERE ID > 100 FOR UPDATE;? 在查詢返回的記錄集中將會有一個新的子記錄。這與事務的隔離規則相違背的：一個事務必須能夠順串(run)， 因而在事務處理中所讀取的數據將不會發生改變。而新的 'phantom' 子記錄將會打破這個隔離規則。

當 InnoDB 掃描索引時，它同樣會鎖定在索引中在結尾記錄(the last record)之后的間隙。這僅僅在上例中會發生： InnoDB 設置的鎖定將阻止任何 ID 大于 100 的插入。 在應用程序中可以通過一個 next-key locking 來實現一個唯一性(uniqueness)檢查：如果以一個共享模式讀取數據并沒有發現與將要插入的數據存在重復值， 那么在讀取過程中 next-key lock 將被設置在你的記錄的后繼者(successor)上，這將阻止其它用戶在期間插入相同的記錄，因而你可以安全地插入你的記錄。

所以， next-key locking 可以允許你 'lock' 你的表中并不存在的記錄。???? InnoDB 中的隔離級詳細描述：? READ UNCOMMITTED 這通常稱為 'dirty read'：non-locking SELECTs 的執行使我們不會看到一個記錄的可能更早的版本；因而在這個隔離度下是非 'consistent' reads；另外，這級隔離的運作如同 READ COMMITTED。

READ COMMITTED 有些類似 Oracle 的隔離級。所有 SELECT ... FOR UPDATE 和 SELECT ... LOCK IN SHARE MODE 語句只鎖定索引記錄，而不鎖定之前的間隙，因而允許在鎖定的記錄后自由地插入新記錄。以一個唯一地搜索條件使用一個唯一索引(unique index)的 UPDATE 和 DELETE，僅僅只鎖定所找到的索引記錄，而不鎖定該索引之前的間隙。但是在范圍型的 UPDATE and DELETE 中，InnoDB 必須設置 next-key 或

gap locks 來阻塞其它用戶對范圍內的空隙插入。 自從為了 MySQL 進行復制(replication)與恢復(recovery)工作'phantom rows'必須被阻塞以來，這就是必須的了。Consistent reads 運作方式與 Oracle 有點類似： 每一個 consistent read，甚至是同一個事務中的，均設置并作用它自己的最新快照。

REPEATABLE READ 這是 InnoDB 默認的事務隔離級。. SELECT ... FOR UPDATE, SELECT ... LOCK IN SHARE MODE, UPDATE, 和 DELETE ，這些以唯一條件搜索唯一索引的，只鎖定所找到的索引記錄，而不鎖定該索引之前的間隙。否則這些操作將使用 next-key 鎖定，以 next-key 和 gap locks 鎖定找到的索引范圍，并阻塞其它用戶的新建插入。在 consistent reads 中，與前一個隔離級相比這是一個重要的差別：在這一級中，同一事務中所有的

consistent reads 均讀取第一次讀取時已確定的快照。這個約定就意味著如果在同一事務中發出幾個無格式(plain)的 SELECTs ，這些 SELECTs 的相互關系是一致的。

SERIALIZABLE 這一級與上一級相似，只是無格式(plain)的 SELECTs 被隱含地轉換為 SELECT ... LOCK IN SHARE MODE。

總結

以上是生活随笔為你收集整理的mysql事务模式怎么查_Mysql InnoDB中的查询事务模式与锁定select ..for update的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。