(multiversion concurrency control)1.先引用《高效能mysql》中對mvcc的部分介紹
2.可以了解到:3.另外, 《高效能mysql》中提到, innodb的mvcc是通過在每行記錄後面儲存兩個隱藏的列來實現的..... 這個貌似和網上很多觀點不同, 具體可以參考mysql官方對innodb-mvcc的解釋
可以看到, innodb儲存引擎在資料庫每行資料的後面新增了三個字段, 不是兩個!!
1.innodb儲存引擎在資料庫每行資料的後面新增了三個字段
2.下面來演示一下事務對某行記錄的更新過程:
3.read view
設該行的當前事務id為trx_id_current,read view中該行最早的事務id為trx_id_first, 最遲的事務id為trx_id_last
如果trx_id_current < trx_id_first, 那就表示
當前事務在讀取該行記錄的時候, 給該行資料設定的隱藏事務id欄位的值, 比read view中記錄的 '當前系統中其他事務給該行記錄設定的事務id都要小'。
這就意味著, 當前所有和該行記錄有關的事務中, 當前事務是第乙個讀取到該行記錄的, 沒有任何在當前事務前面對該行資料做過更改但還沒有提交的事務, 所以當前事務可以直接拿到表中穩定的資料!
如果trx_id_current > trx_id_last的話，那就表示
當前事務在讀取該行記錄的時候, 給該行資料設定的隱藏事務id欄位的值, 比read view中記錄的 '當前系統中其他事務給該行記錄設定的事務id都要大'。
這就意味著, 當前所有和該行記錄有關的事務中, 當前事務是最後乙個讀取到該行記錄的, 所以需要從該行記錄的db_roll_ptr指標所指向的回滾段中取出最新的undo-log的版本號, 將它賦值給trx_id_current，然後繼續重新開始整套比較演算法, 這麼迭代下去, 會在undo-log中一層層往下找下去, 最終就會取到穩定的資料!
如果trx_id_first < trx_id_current < trx_id_last, 同上;
之前已經了解到 mvcc只在read committed和repeatable read兩個隔離級別下工作;
並且根據read view的生成原則, 導致在這兩個不同隔離級別下,read committed總是讀最新乙份快照資料, 而repeatable read 讀事務開始時的行資料版本;
一般我們認為mvcc有下面幾個特點：
而innodb實現mvcc的方式是:
二者最本質的區別是: 當修改資料時是否要排他鎖定，如果鎖定了還算不算是mvcc？
Mysql知識延展（七）MVCC多版本併發控制
mvcc簡述 mvcc mutil version concurrency control 就是多版本併發控制。mvcc 是一種併發控制的方法，一般在資料庫管理系統中，實現對資料庫讀寫的併發訪問。在mysql的innodb引擎中就是指在已提交讀 read committd 和可重複讀 repeata...
MySql 事務詳解與 MVCC 多版本併發控制
原子性 atomicity 事務包含的所有操作要麼全部成功，要麼全部失敗回滾。一致性 consistency 事務必須使資料庫從乙個一致性狀態變換到另乙個一致性狀態，也就是說乙個事務執行之前和執行之後都必須處於一致性狀態。隔離性 isolation 事務之間相互隔離不被干擾。永續性 durabili...
多版本併發控制
多版本併發控制，討論的不是指的乙個軟體同時發行多個版本怎麼進行管理的問題，而是mysql中的mvcc。mvcc，multiple version concurrent control，多版本併發控制。可以認為mvcc是行級鎖的乙個變種，但它在很多情況下避免了加鎖操作，因此開銷更低。雖然實現機制有所不...