在mysql的眾多儲存引擎中，只有innodb支援事務，所有這裡說的事務隔離級別指的是innodb下的事務隔離級別。
讀未提交：乙個事務可以讀取到另乙個事務未提交的修改。這會帶來髒讀、幻讀、不可重複讀問題。（基本沒用）
讀已提交：乙個事務只能讀取另乙個事務已經提交的修改。其避免了髒讀，但仍然存在不可重複讀和幻讀問題。
可重複讀：同乙個事務中多次讀取相同的資料返回的結果是一樣的。其避免了髒讀和不可重複讀問題，但幻讀依然存在。
序列化：事務序列執行。避免了以上所有問題。
以上是sql-92標準中定義的四種隔離級別。在mysql中，預設的隔離級別是repeatable-read（可重複讀），並且解決了幻讀問題。簡單的來說，mysql的預設隔離級別解決了髒讀、幻讀、不可重複讀問題。
不可重複讀重點在於update和delete，而幻讀的重點在於insert。
在這裡，我們只討論可重複讀。
譯註：mvcc的全稱是「多版本併發控制」。這項技術使得innodb的事務隔離級別下執行一致性讀操作有了保證，換言之，就是為了查詢一些正在被另乙個事務更新的行，並且可以看到它們被更新之前的值。這是乙個可以用來增強併發性的強大的技術，因為這樣的一來的話查詢就不用等待另乙個事務釋放鎖。這項技術在資料庫領域並不是普遍使用的。一些其它的資料庫產品，以及mysql其它的儲存引擎並不支援它。
說明網上看到大量的文章講到mvcc都是說給沒一行增加兩個隱藏的字段分別表示行的建立時間以及過期時間，它們儲存的並不是時間，而是事務版本號。
事實上，這種說法並不準確，嚴格的來講，innodb會給資料庫中的每一行增加三個字段，它們分別是db_trx_id、db_roll_ptr、db_row_id。
但是，為了理解的方便，我們可以這樣去理解，索引接下來的講解中也還是用這兩個欄位的方式去理解。
增刪查改
在innodb中，給每行增加兩個隱藏欄位來實現mvcc，乙個用來記錄資料行的建立時間，另乙個用來記錄行的過期時間（刪除時間）。在實際操作中，儲存的並不是時間，而是事務的版本號，每開啟乙個新事務，事務的版本號就會遞增。
於是乎，預設的隔離級別（repeatable read）下，增刪查改變成了這樣：
insert
update
delete
快照讀和當前讀
快照讀：讀取的是快照版本，也就是歷史版本
當前讀：讀取的是最新版本
普通的select就是快照讀，而update、delete、insert、select ... lock in share mode、select ... for update是當前讀。
鎖定讀在乙個事務中，標準的select語句是不會加鎖，但是有兩種情況例外。select ... lock in share mode 和 select ... for update。
select ... lock in share mode
給記錄假設共享鎖，這樣一來的話，其它事務只能讀不能修改，直到當前事務提交
select ... for update
給索引記錄加鎖，這種情況下跟update的加鎖情況是一樣的
一致性非鎖定讀
consistent read （一致性讀），innodb用多版本來提供查詢資料庫在某個時間點的快照。如果隔離級別是repeatable read，那麼在同乙個事務中的所有一致性讀都讀的是事務中第乙個這樣的讀讀到的快照；如果是read committed，那麼乙個事務中的每乙個一致性讀都會讀到它自己重新整理的快照版本。consistent read（一致性讀）是read committed和repeatable read隔離級別下普通select語句預設的模式。一致性讀不會給它所訪問的表加任何形式的鎖，因此其它事務可以同時併發的修改它們。
悲觀鎖，正如它的名字那樣，資料庫總是認為別人會去修改它所要操作的資料，因此在資料庫處理過程中將資料加鎖。其實現依靠資料庫底層。
樂觀鎖，如它的名字那樣，總是認為別人不會去修改，只有在提交更新的時候去檢查資料的狀態。通常是給資料增加乙個欄位來標識資料的版本。
有這樣三種鎖我們需要了解
假設乙個索引包含以下幾個值：10,11,13,20。那麼這個索引的next-key鎖將會覆蓋以下區間：
(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)
了解了以上概念之後，接下來具體就簡單分析下repeatable read隔離級別是如何實現的
之所以說是理論分析，是因為要是實際操作證明的話我也不知道怎麼去證明，畢竟作者水平實在有限。
但是，這並不意味著我在此胡說八道，有官方文件為證。
這段話的大致意思是，在預設的隔離級別中，普通的select用的是一致性讀不加鎖。而對於鎖定讀、update和delete，則需要加鎖，至於加什麼鎖視情況而定。如果你對乙個唯一索引使用了唯一的檢索條件，那麼只需鎖定索引記錄即可；如果你沒有使用唯一索引作為檢索條件，或者用到了索引範圍掃瞄，那麼將會使用間隙鎖或者next-key鎖以此來阻塞其它會話向這個範圍內的間隙插入資料。
作者曾經有乙個誤區，認為按照前面說mvcc下的增刪查改的行為就不會出現任何問題，也不會出現不可重複讀和幻讀。但其實是大錯特錯。
舉個很簡單的例子，假設事務a更新表中id=1的記錄，而事務b也更新這條記錄，並且b先提交，如果按照前面mvvc說的，事務a讀取id=1的快照版本，那麼它看不到b所提交的修改，此時如果直接更新的話就會覆蓋b之前的修改，這就不對了，可能b和a修改的不是乙個字段，但是這樣一來，b的修改就丟失了，這是不允許的。
所以，在修改的時候一定不是快照讀，而是當前讀。
而且，前面也講過只有普通的select才是快照讀，其它諸如update、刪除都是當前讀。修改的時候加鎖這是必然的，同時為了防止幻讀的出現還需要加間隙鎖。
回想一下
1、利用mvcc實現一致性非鎖定讀，這就***在同乙個事務中多次讀取相同的資料返回的結果是一樣的，解決了不可重複讀的問題
2、利用gap locks和next-key可以阻止其它事務在鎖定區間內插入資料，因此解決了幻讀問題
綜上所述，預設隔離級別的實現依賴於mvcc和鎖，再具體一點是一致性讀和鎖。
MySQL事務隔離級別的實現原理
在mysql的眾多儲存引擎中，只有innodb支援事務，所有這裡說的事務隔離級別指的是innodb下的事務隔離級別。讀未提交 乙個事務可以讀取到另乙個事務未提交的修改。這會帶來髒讀 幻讀 不可重複讀問題。基本沒用 讀已提交 乙個事務只能讀取另乙個事務已經提交的修改。其避免了髒讀，但仍然存在不可重複讀...
mysql 事務隔離級別的實現原理
目錄 一 事務的四要素 acid 二 mysql的事務的隔離級別 三 多版本併發控制 multi version concurrency control 3.1 功能 3.2 原理 1.原子性 atomicity all done 或者 all not done 2.一致性 consistency ...
MySQL事務隔離級別的實現原理
mysql的acid mysql的隔離級別 在mysql的眾多儲存引擎中，只有innodb支援事務，所有這裡說的事務隔離級別指的是innodb下的事務隔離級別。讀未提交 乙個事務可以讀取到另乙個事務未提交的修改。這會帶來髒讀 幻讀 不可重複讀問題。基本沒用 讀已提交 乙個事務只能讀取另乙個事務已經提...