1.mvcc簡(jiǎn)介

1.1mvcc定義

mvcc(Multi Version Concurrency Control)，多版本并發(fā)控制，是一種數(shù)據(jù)庫(kù)的并發(fā)控制機(jī)制。它用于管理事務(wù)并發(fā)執(zhí)行時(shí)對(duì)數(shù)據(jù)的訪問和修改，保證在多個(gè)事務(wù)同時(shí)對(duì)數(shù)據(jù)庫(kù)進(jìn)行讀寫操作，不會(huì)出現(xiàn)數(shù)據(jù)不一致或丟失的情況

1.2mvcc解決的問題

當(dāng)多個(gè)事務(wù)同時(shí)訪問數(shù)據(jù)庫(kù)中的相同數(shù)據(jù)時(shí)，可能會(huì)有幾種情況：

• 讀：多個(gè)事務(wù)都是讀操作，不會(huì)產(chǎn)生并發(fā)問題
• 讀+寫：事務(wù)有讀有寫，那么會(huì)產(chǎn)生臟讀、不可重復(fù)讀、幻讀的問題
• 寫：多個(gè)事務(wù)同時(shí)寫，可能會(huì)產(chǎn)生數(shù)據(jù)丟失、覆蓋等問題

針對(duì)以上問題，在讀+寫的情況下，通常需要加鎖來(lái)解決問題，mysql的innodb實(shí)現(xiàn)了mvcc來(lái)更好的處理讀寫沖突，做到不用加鎖，實(shí)現(xiàn)非阻塞并發(fā)讀

在都是寫操作的情況下，只能通過加鎖的方式解決。

1.3當(dāng)前讀與快照讀

當(dāng)前讀：讀取的是最新版本的數(shù)據(jù)，保證讀取時(shí)不會(huì)有其他事務(wù)修改數(shù)據(jù)，需要對(duì)記錄加鎖

加共享鎖，讀不受影響，寫會(huì)被阻塞

select ... lock in share mode;

加排他鎖，讀和寫都被阻塞（快照讀不受影響）

select ... for update;

更新、插入、刪除操作以及串行化隔離級(jí)別都是當(dāng)前讀

快照讀：每一次修改數(shù)據(jù)，都會(huì)在undolog中存有原始記錄（快照），快照讀就是讀取某一版本的記錄。這種方式能夠不加鎖讀數(shù)據(jù)，但是可能會(huì)讀到舊的數(shù)據(jù)。一般的查詢都是快照讀

select * from tablename;

2.mvcc原理

mvcc主要通過行記錄中的隱藏字段、undolog和readview實(shí)現(xiàn)的

2.1隱藏字段

mysql的innodb引擎中，在每一行記錄中除了自定義的字段，還有3個(gè)隱藏的字段（innodb引擎）

• row_id：如果表沒有自定義主鍵，那么會(huì)自動(dòng)生成row_id作為主鍵
• trx_id：記錄修改、新增這條記錄的事務(wù)id
• roll_pointer：回滾指針，指向當(dāng)前記錄的上一個(gè)版本

2.2版本鏈

在修改數(shù)據(jù)時(shí)，mysql會(huì)向undolog中記錄數(shù)據(jù)原來(lái)的快照，用于進(jìn)行回滾操作。undolog還能用來(lái)實(shí)現(xiàn)mvcc

如以下例子，mvcc生成版本鏈：

當(dāng)事務(wù)1001（trx_id=1001）執(zhí)行了 insert into user values(1,'竹子',23) 之后：

當(dāng)事務(wù)1002（trx_id=1002）執(zhí)行了 update user set name='竹筍' where id=1 之后：

當(dāng)事務(wù)1003（trx_id=1003）執(zhí)行了 update user set name='竹葉' where id=1 之后：

可以看到，不同版本的數(shù)據(jù)被指針連接起來(lái)形成了一個(gè)鏈表。

當(dāng)我們要讀取時(shí)，如何判斷該讀取哪個(gè)版本呢？這就與生成的讀視圖有關(guān)了。

2.3ReadView

讀視圖用于決定事務(wù)可以讀到哪個(gè)版本的數(shù)據(jù)

它包含以下主要信息：

• trx_ids：當(dāng)前mysql中所有活躍的事務(wù)id集合（沒提交或回滾的事務(wù)集）
• low_limit_id：當(dāng)前出現(xiàn)的最大的事務(wù)id+1，表示下一個(gè)要分配的事務(wù)id
• up_limit_id：當(dāng)前活躍的事務(wù)id集合中，最小的事務(wù)id
• creator_trx_id：生成該ReadView視圖的事務(wù)的id

MySQL5.7版本的源碼對(duì)于這些信息的定義如下：

插入一個(gè)注意事項(xiàng)：????????????????????????

start transaction不代表立即生成ReadView，而是在事務(wù)中第一次快照讀的時(shí)候生成ReadView，具體參考MySQL可重復(fù)讀隔離級(jí)別下開啟事務(wù)的一個(gè)注意事項(xiàng)

想要開啟事務(wù)時(shí)就生成ReadView，請(qǐng)使用：

start transaction with consistent snapshot;

2.4讀視圖生成原則

ReadView定義了一個(gè)可見性算法，當(dāng)事務(wù)進(jìn)行快照讀時(shí)，依據(jù)該算法判斷事務(wù)能夠讀取哪個(gè)快照。

源碼的可見性判斷邏輯如下：(下載源碼可訪問：官網(wǎng)，操作系統(tǒng)選擇Source Code)

/** Check whether the changes by id are visible.
	@param[in]	id	transaction id to check against the view
	@param[in]	name	table name
	@return whether the view sees the modifications of id. */
//判斷某個(gè)版本的數(shù)據(jù)是否對(duì)當(dāng)前事務(wù)可見
bool changes_visible(
    trx_id_t		id,
    const table_name_t&	name) const
    MY_ATTRIBUTE((warn_unused_result)) {
    ut_ad(id > 0);
    //快照的id小于活躍事務(wù)id集合中的最小事務(wù)id 或者 快照的id等于創(chuàng)建這個(gè)視圖的事務(wù)id
    if (id < m_up_limit_id || id == m_creator_trx_id) {
        return(true);
    }
    //檢查快照id是否合法，如果快照的id大于等于下一要分配的事務(wù)id，則需要拋出警告信息（會(huì)出現(xiàn)這種情況嗎？）
    check_trx_id_sanity(id, name);
    //快照的id大于等于下一要分配的事務(wù)id
    if (id >= m_low_limit_id) {
        return(false);
    } 
    //當(dāng)前不存在活躍的事務(wù)
    else if (m_ids.empty()) {
        return(true);
    }
    const ids_t::value_type*	p = m_ids.data();
    //通過二分查找判斷快照id是否在活躍事務(wù)集合中，存在則快照不可見，不存在則快照可見
    return(!std::binary_search(p, p + m_ids.size(), id));
}

• 當(dāng)快照id等于當(dāng)前事務(wù)id時(shí)（trx_id=creator_trx_id），說(shuō)明該版本是當(dāng)前事務(wù)修改的，該快照對(duì)當(dāng)前事務(wù)可見
• 當(dāng)快照id小于活躍事務(wù)的最小id（trx_id<up_limit_id），說(shuō)明該版本對(duì)應(yīng)的事務(wù)已經(jīng)提交了，該快照對(duì)當(dāng)前事務(wù)可見
• 當(dāng)快照id大于等于下一個(gè)要分配的事務(wù)id（trx_id>=low_limit_id），則該快照對(duì)當(dāng)前事務(wù)不可見
• 當(dāng)快照id小于下一個(gè)要分配的事務(wù)id并且活躍事務(wù)id數(shù)量為0（trx_id<low_limit_id && trx_ids.size==0），則該快照對(duì)當(dāng)前事務(wù)可見
• 當(dāng)以上條件都不滿足，則在活躍事務(wù)id集合里查找快照id，如果不存在，則可見，否則不可見

3.rc和rr隔離級(jí)別下mvcc的不同

mvcc主要用來(lái)解決rc（讀已提交）隔離級(jí)別下的臟讀和rr（可重復(fù)讀）隔離級(jí)別的不可重復(fù)讀問題，所以mvcc只在rc和rr隔離級(jí)別下生效。

區(qū)別在于，rc級(jí)別下，每一次快照讀都會(huì)生成一個(gè)最新的ReadView；RR級(jí)別下，只有事務(wù)中的第一次快照讀會(huì)生成ReadView，之后的快照讀會(huì)使用第一次生成的ReadView。

事務(wù)能否查詢到其他事物修改的數(shù)據(jù)，取決于ReadView，而rc和rr兩個(gè)級(jí)別的ReadView生成方式不同，就導(dǎo)致了事務(wù)可見性不同。（rc級(jí)別下一個(gè)事務(wù)可以查詢到其他事物在此期間修改并提交的數(shù)據(jù)，因?yàn)樗拿看尾樵兌紩?huì)生成新的ReadView；rr級(jí)別下事務(wù)無(wú)法查詢到其他事物在此期間修改并提交的數(shù)據(jù)，因?yàn)樗腞eadView只在第一次快照讀生成）

到此這篇關(guān)于MySQL多版本并發(fā)控制mvcc原理淺析的文章就介紹到這了,更多相關(guān)MySQL多版本并發(fā)控制mvcc內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論