先重申下隔離級別的特性 | 隔離級別 | 臟讀可能性 | 不可重復可能性 | 幻讀可能性 | 加鎖讀 | | --- | --- | --- | --- | --- | | READ UNCOMMITTED | Yes | Yes | Yes | No | | READ COMMITTED | No | Yes | Yes | No | | REPEATABLE READ | No | No | Yes | No | | SERIALIZABLE | No | No | No | Yes | ### MVCC機制 InnoDB的**一致性的非鎖定讀**就是通過在MVCC實現的，Mysql的大多數事務型存儲引擎實現的都不是簡單的行級鎖。基于提升并發性能的考慮，它們一般都同時實現了多版本并發控制（MVCC）。MVCC的實現，是通過保存數據在某一個時間點的快照來實現的。因此每一個事務無論執行多長時間看到的數據，都是一樣的。所以MVCC實現可重復讀。 * 快照讀：select語句默認，不加鎖，MVCC實現可重復讀，使用的是MVCC機制讀取undo中的已經提交的數據。所以它的讀取是非阻塞的 * 當前讀：select語句加S鎖或X鎖；所有的修改操作加X鎖，在select for update 的時候，才是當地前讀。 *RR隔離級別下的快照讀，不是以begin開始的時間點作為snapshot建立時間點，而是以第一條select語句的時間點作為snapshot建立的時間點。* # 什么是MVCC? 英文全稱為Multi-Version Concurrency Control,翻譯為中文即 多版本并發控制。在小編看來，他無非就是樂觀鎖的一種實現方式。在Java編程中，如果把樂觀鎖看成一個接口，MVCC便是這個接口的一個實現類而已。  # 特點 1.MVCC其實廣泛應用于數據庫技術，像Oracle,PostgreSQL等也引入了該技術，即適用范圍廣 2.MVCC并沒有簡單的使用數據庫的行鎖，而是使用了行級鎖，row\_level\_lock,而非InnoDB中的innodb\_row\_lock. # 基本原理 MVCC的實現，通過保存數據在某個時間點的快照來實現的。這意味著一個事務無論運行多長時間，在同一個事務里能夠看到數據一致的視圖。根據事務開始的時間不同，同時也意味著在同一個時刻不同事務看到的相同表里的數據可能是不同的。 # 基本特征 * 每行數據都存在一個版本，每次數據更新時都更新該版本。 * 修改時Copy出當前版本隨意修改，各個事務之間無干擾。 * 保存時比較版本號，如果成功（commit），則覆蓋原記錄；失敗則放棄copy（rollback） # InnoDB存儲引擎MVCC的實現策略 在每一行數據中額外保存兩個隱藏的列：當前行創建時的版本號和刪除時的版本號（可能為空，其實還有一列稱為回滾指針，用于事務回滾，不在本文范疇）。這里的版本號并不是實際的時間值，而是系統版本號。每開始新的事務，系統版本號都會自動遞增。事務開始時刻的系統版本號會作為事務的版本號，用來和查詢每行記錄的版本號進行比較。 每個事務又有自己的版本號，這樣事務內執行CRUD操作時，就通過版本號的比較來達到數據版本控制的目的。 # MVCC下InnoDB的增刪查改是怎么work的 1.插入數據（insert）:記錄的版本號即當前事務的版本號 執行一條數據語句：insert into testmvcc values(1,"test"); 假設事務id為1，那么插入后的數據行如下：  2、在更新操作的時候，采用的是先標記舊的那行記錄為已刪除，并且刪除版本號是事務版本號，然后插入一行新的記錄的方式。 比如，針對上面那行記錄，事務Id為2 要把name字段更新 update table set name= 'new\_value' where id=1;  3、刪除操作的時候，就把事務版本號作為刪除版本號。比如 delete from table where id=1;  4、查詢操作： 從上面的描述可以看到，在查詢時要符合以下兩個條件的記錄才能被事務查詢出來： 1) 刪除版本號未指定或者大于當前事務版本號，即查詢事務開啟后確保讀取的行未被刪除。(即上述事務id為2的事務查詢時，依然能讀取到事務id為3所刪除的數據行) 2) 創建版本號 小于或者等于 當前事務版本號 ，就是說記錄創建是在當前事務中（等于的情況）或者在當前事務啟動之前的其他事物進行的insert。 （即事務id為2的事務只能讀取到create version<=2的已提交的事務的數據集） > 補充： > > 1.MVCC手段只適用于Msyql隔離級別中的讀已提交（Read committed）和可重復讀（Repeatable Read）. > > 2.Read uncimmitted由于存在臟讀，即能讀到未提交事務的數據行，所以不適用MVCC. > > 原因是MVCC的創建版本和刪除版本只要在事務提交后才會產生。 > > 3.串行化由于是會對所涉及到的表加鎖，并非行鎖，自然也就不存在行的版本控制問題。 > > 4.通過以上總結，可知，MVCC主要作用于事務性的，有行鎖控制的數據庫模型。 # 關于Mysql中MVCC的總結 客觀上，我們認為他就是樂觀鎖的一整實現方式，就是每行都有版本號，保存時根據版本號決定是否成功。 但由于Mysql的寫操作會加排他鎖（前文有講），如果鎖定了還算不算是MVCC？ 了解樂觀鎖的小伙伴們，都知道其主要依靠版本控制，即消除鎖定，二者相互矛盾，so從某種意義上來說，Mysql的MVCC并非真正的MVCC，他只是借用MVCC的名號實現了讀的非阻塞而已。