本篇文章為大家帶來了關於mysql的相關知識，其中主要介紹了關於InnoDB之MVCC原理的相關問題，MVCC即多版本並發控制，主要是為了提高資料庫的並發性能，下面一起來看一下，希望對大家有幫助。
推薦學習：mysql影片教學
MVCC全名為Multi-Version Concurrency Control，即多版本並發控制，主要是為了提高資料庫的並發效能。同一行資料平時發生讀寫請求時，會上鎖阻塞住。但MVCC用更好的方式去處理讀取—寫請求，做到發生讀取—寫入請求衝突時不用加鎖。這個讀是指的快照讀，而不是當前讀，當前讀是一種加鎖操作，是悲觀鎖。那它到底是怎麼做到讀—寫不用加鎖的，快照讀和當前讀是指什麼？我們後面都會學到。
MySQL在REPEATABLE READ隔離等級下，是可以很大程度上避免幻讀問題的發生的，MySQL是怎麼做到的？
我們知道，對於使用InnoDB儲存引擎的表來說，它的叢集索引記錄中都包含兩個必要的隱藏欄位（row_id不是必要的，我們建立的表中有主鍵或非NULL的UNIQUE鍵時都不會包含row_id列）：
trx_id：每次一個事務對某條聚簇索引記錄進行改動時，都會把該交易的交易id賦值給trx_id隱藏欄位。
roll_pointer：每次對某一叢集索引記錄進行改動時，都會把舊的版本寫入到undo日誌中，然後這個隱藏列就相當於一個指針，可以透過它來找到該記錄修改前的資訊。
為了說明這個問題，我們建立一個演示表：
CREATE TABLE `teacher` ( `number` int(11) NOT NULL, `name` varchar(100) DEFAULT NULL, `domain` varchar(100) DEFAULT NULL, PRIMARY KEY (`number`)) ENGINE=InnoDB DEFAULT CHARSET=utf8
然後向這個表裡插入一條數據：
mysql> insert into teacher values(1, 'J', 'Java');Query OK, 1 row affected (0.01 sec)
現在裡的數據就是這樣的：
mysql> select * from teacher; +--------+------+--------+ | number | name | domain | +--------+------+--------+ | 1 | J | Java | +--------+------+--------+ 1 row in set (0.00 sec)
假設插入該記錄的事務id為60，那麼此刻該記錄的示意圖如下所示：
假設之後兩個事務id分別為80、120的事務對這條記錄進行UPDATE操作，操作流程如下：
| #Trx80 | Trx120 |
|---|---|
| begin | |
| #begin | |
|
update teacher set name='S' where number=1; |
|
|
update teacher set name='T' where number=1; |
|
| commit | |
每次对记录进行改动，都会记录一条undo日志，每条undo日志也都有一个roll_pointer属性（INSERT操作对应的undo日志没有该属性，因为该记录并没有更早的版本），可以将这些undo日志都连起来，串成一个链表，所以现在的情况就像下图一样：
对该记录每次更新后，都会将旧值放到一条undo日志中，就算是该记录的一个旧版本，随着更新次数的增多，所有的版本都会被roll_pointer属性连接成一个链表，我们把这个链表称之为版本链，版本链的头节点就是当前记录最新的值。另外，每个版本中还包含生成该版本时对应的事务id。于是可以利用这个记录的版本链来控制并发事务访问相同记录的行为，那么这种机制就被称之为多版本并发控制(Mulit-Version Concurrency Control MVCC)。
对于使用READ UNCOMMITTED隔离级别的事务来说，由于可以读到未提交事务修改过的记录，所以直接读取记录的最新版本就好了。
对于使用SERIALIZABLE隔离级别的事务来说，InnoDB使用加锁的方式来访问记录。
对于使用READ COMMITTED和REPEATABLE READ隔离级别的事务来说，都必须保证读到已经提交了的事务修改过的记录，也就是说假如另一个事务已经修改了记录但是尚未提交，是不能直接读取最新版本的记录的，核心问题就是：READ COMMITTED和REPEATABLE READ隔离级别在不可重复读和幻读上的区别，这两种隔离级别关键是需要判断一下版本链中的哪个版本是当前事务可见的。
为此，InnoDB提出了一个ReadView的概念，这个ReadView中主要包含4个比较重要的内容：
m_ids：表示在生成ReadView时当前系统中活跃的读写事务的事务id列表。
min_trx_id：表示在生成ReadView时当前系统中活跃的读写事务中最小的事务id，也就是m_ids中的最小值。
max_trx_id：表示生成ReadView时系统中应该分配给下一个事务的id值。注意max_trx_id并不是m_ids中的最大值，事务id是递增分配的。比方说现在有id为1，2，3这三个事务，之后id为3的事务提交了。那么一个新的读事务在生成ReadView时，m_ids就包括1和2，min_trx_id的值就是1，max_trx_id的值就是4。
creator_trx_id：表示生成该ReadView的事务的事务id。
有了这个ReadView，这样在访问某条记录时，只需要按照下边的步骤判断记录的某个版本是否可见：
在MySQL中，READ COMMITTED和REPEATABLE READ隔离级别的的一个非常大的区别就是它们生成ReadView的时机不同。
我们还是以表teacher为例，假设现在表teacher中只有一条由事务id为60的事务插入的一条记录，接下来看一下READ COMMITTED和REPEATABLE READ所谓的生成ReadView的时机不同到底不同在哪里。
假设现在系统里有两个事务id分别为80、120的事务在执行：
# Transaction 80 set session transaction isolation level read committed; begin update teacher set name='S' where number=1; update teacher set name='T' where number=1;
此刻，表teacher中number为1的记录得到的版本链表如下所示：
假设现在有一个使用READ COMMITTED隔离级别的事务开始执行：
set session transaction isolation level read committed; # 使用READ COMMITTED隔离级别的事务 begin; # SELECE1：Transaction 80、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J'
这个SELECE1的执行过程如下：
在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[80, 120]，min_trx_id为80，max_trx_id为121，creator_trx_id为0。
然后从版本链中挑选可见的记录，最新版本的列name的内容是’T’，该版本的trx_id值为80，在m_ids列表内，根据步骤4不符合可见性要求，根据roll_pointer跳到下一个版本。
下一个版本的列name的内容是’S’，该版本的trx_id值也为80，也在m_ids列表内，根据步骤4也不符合要求，继续跳到下一个版本。
下一个版本的列name的内容是’J’，该版本的trx_id值为60，小于ReadView 中的min_trx_id值，根据步骤2判断这个版本是符合要求的。
之后，我们把事务id为80的事务提交一下，然后再到事务id为120的事务中更新一下表teacher 中number为1的记录：
set session transaction isolation level read committed; # Transaction 120 begin update teacher set name='K' where number=1; update teacher set name='F' where number=1;
此刻，表teacher 中number为1的记录的版本链就长这样：
然后再到刚才使用READ COMMITTED隔离级别的事务中继续查找这个number 为1的记录，如下：
# 使用READ COMMITTED隔离级别的事务 begin; # SELECE1：Transaction 80、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J' # SELECE2：Transaction 80提交、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'T'
这个SELECE2 的执行过程如下：
以此类推，如果之后事务id为120的记录也提交了，再次在使用READCOMMITTED隔离级别的事务中查询表teacher中number值为1的记录时，得到的结果就是’F’了，具体流程我们就不分析了。
总结一下就是：使用READCOMMITTED隔离级别的事务在每次查询开始时都会生成一个独立的ReadView。
对于使用REPEATABLE READ隔离级别的事务来说，只会在第一次执行查询语句时生成一个ReadView，之后的查询就不会重复生成了。我们还是用例子看一下是什么效果。
假设现在系统里有两个事务id分别为80、120的事务在执行：
# Transaction 80 begin update teacher set name='S' where number=1; update teacher set name='T' where number=1;
此刻，表teacher中number为1的记录得到的版本链表如下所示：
假设现在有一个使用REPEATABLE READ隔离级别的事务开始执行：
# 使用REPEATABLE READ隔离级别的事务 begin; # SELECE1：Transaction 80、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J'
这个SELECE1的执行过程如下（与READ COMMITTED的过程一致）：
在执行SELECT语句时会先生成一个ReadView，ReadView的m_ids列表的内容就是[80, 120]，min_trx_id为80，max_trx_id为121，creator_trx_id为0。
然后从版本链中挑选可见的记录，最新版本的列name的内容是’T’，该版本的trx_id值为80，在m_ids列表内，根据步骤4不符合可见性要求，根据roll_pointer跳到下一个版本。
下一个版本的列name的内容是’S’，该版本的trx_id值也为80，也在m_ids列表内，根据步骤4也不符合要求，继续跳到下一个版本。
下一个版本的列name的内容是’J’，该版本的trx_id值为60，小于ReadView 中的min_trx_id值，根据步骤2判断这个版本是符合要求的。
之后，我们把事务id为80的事务提交一下，然后再到事务id为120的事务中更新一下表teacher 中number为1的记录：
# Transaction 80 begin update teacher set name='K' where number=1; update teacher set name='F' where number=1;
此刻，表teacher 中number为1的记录的版本链就长这样：
然后再到刚才使用REPEATABLE READ隔离级别的事务中继续查找这个number为1的记录，如下：
# 使用REPEATABLE READ隔离级别的事务 begin; # SELECE1：Transaction 80、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J' # SELECE2：Transaction 80提交、120未提交 SELECT * FROM teacher WHERE number = 1; # 得到的列name的值为'J'
这个SELECE2的执行过程如下：
也就是說兩次SELECT查詢得到的結果是重複的，記錄的列值都是’’‘J’’’，這就是可重複讀取的意思。
如果我們之後再把事務id為120的記錄提交了，然後再到剛才使用REPEATABLE READ隔離級別的事務中繼續查找這個number為1的記錄，得到的結果還是'J'，具體執行過程大家可以自己分析一下。
前面我們已經知道了，REPEATABLE READ隔離等級下MVCC可以解決不可重複讀取問題，那麼幻讀呢？ MVCC是怎麼解決的？幻讀是當一個事務按照某個相同條件多次讀取記錄時，後讀取時讀到了之前沒有讀到的記錄，而這個記錄來自另一個事務添加的新記錄。
我們可以想想，在REPEATABLE READ隔離等級下的事務T1先根據某個搜尋條件讀取到多筆記錄，然後事務T2插入一條符合對應搜尋條件的記錄並提交，然後事務T1再根據相同搜尋條件執行查詢。結果會是什麼？依照ReadView中的比較規則：
不管事務T2比事務T1是否先開啟，事務T1都是看不到T2的提交的。請自行按照上面介紹的版本鏈、ReadView以及判斷可見性的規則來分析一下。
但是，在REPEATABLE READ隔離等級下InnoDB中的MVCC可以很大程度上地避免幻讀現象，而不是完全禁止幻讀。怎麼回事呢？我們來看下面的情況：
| T1 | T2 |
|---|---|
| begin; | |
以上是MySQL歸納總結InnoDB之MVCC原理的詳細內容。更多資訊請關注PHP中文網其他相關文章！
