本篇內容主要講解“MVCC的概念是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“MVCC的概念是什么”吧!
MVCC使得大部分支持行鎖的事務引擎，不再單純的使用行鎖來進行數據庫的并發控制，而是把數據庫的行鎖和行的版本號結合起來，只需要很小的開銷，就可以實現非鎖定讀。從而提高數據庫的并發性能。
MVCC是采用無鎖的形式解決讀-寫沖突問題。這里的讀是指的快照讀。即MVCC實現的快照讀?。?！
多版本并發控制（MVCC）是一種解決讀-寫沖突的無鎖并發控制。
每一行記錄都有兩個隱藏列：創建版本號和回滾指針。事務開啟后存在一個事務id。多個并發事務同時操作某行，不同的事務對該行update操作會產生多個版本，然后通過回滾指針組成undo log鏈。而MVCC的快照讀正是通過事務id和創建版本號從而實現的快照讀。
MVCC是為了解決讀-寫問題。且通過不同的配置，也可以解決事務開啟后，快照讀不可重復讀的問題。
不可重復讀：同一個事務中讀取某些數據已經發生改變，或某些記錄已經刪除。
幻讀：一個事務按照相同的查詢條件重新讀取以前檢索過的數據，卻發現其他事務插入了滿足查詢條件的新數據，這種現象被稱為幻讀。
RC和RR均實現了MVCC，但是為什么RR解決了RC不可重復讀的問題？
你可以這樣認為，RC之所以有不可重復讀的問題，只是因為開發者有意設置的（設置多種隔離級別，用戶可以根據情況設置）。本來數據都提交到數據庫了，RC讀取出來也沒什么問題呀？況且Oracle數據庫本身的隔離級別就是RC。
READ-COMMITTED（讀已提交）
讀已提交RC，在這一隔離級別下，可以在SQL級別做到一致性讀，每次SQL語句都會產生新的ReadView。這就意味著兩次查詢之間有別的事務提交了，是可以讀到不一致的數據的。
REPEATABLE-READ（可重復讀）
可重復讀RR，在第一次創建ReadView后，這個ReadView就會一直維持到事務結束，也就是說，在事務執行期間可見性不會發生變化，從而實現了事務內的可重復讀。
MVCC無鎖解決了讀-寫沖突的問題。并且解決了不可重復讀問題。從而實現了RC和RR兩個隔離級別。
而間隙鎖本質上依舊是鎖，會阻塞兩個并發事務的執行。
那么RR為什么還要進入間隙鎖，難道僅僅為了解決幻讀的問題嗎？
注意：只有RR隔離級別才存在間隙鎖。
間隙鎖在一定程度上可以解決幻讀的問題，但是間隙鎖的引入我覺得更多是為了處理binlog的statement模式的bug。
mysql數據庫的主從復制依靠的是binlog。而在mysql5.0之前，binlog模式只有statement格式。這種模式的特點：binlog的記錄順序是按照數據庫事務commit順序為順序的。
當不存在間隙鎖的情況下，會有如下的場景：
master庫有這么兩個事務：
1、事務a先delete id<6，然后在commit前；
2、事務b直接insert id=3，并且完成commit；
3、事務a進行commit；
此時binlog記錄的日志是：事務b先執行，事務a在執行（binlog記錄的是commit順序）
那么主庫此時表里面有id=3的記錄，但是從庫是先插入再刪除，從庫里面是沒有記錄的。
這就導致了主從數據不一致。
為了解決這個bug，所以RR級別引入了間隙鎖。
到此，相信大家對“MVCC的概念是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
