InnoDB -MVCC多版本併發控制

markzy5201190發表於2013-07-04
MVCC多版本併發控制

原理:
mvcc提供基於某個時間的快照,使得對於事務看來,總是可以提供與事務開始時刻相一致的資料,而不管這個事
務執行的時間有多長,故在不同事務看來,同一時刻看到的相同的行資料可能是不一樣的,即:每一行資料會有
多個版本資料(副本)
InnoDB中每行隱含2個欄位:更新或修改版本號和刪除版本號(可以為空),每一個事務開始也有自己的版本號且是遞增(
類似於SCN)
以select,delete,insert update語句來說明:
1)select 同時滿足2個條件的行,才能被返回:
*行的被修改版本號<=該版本號
*行的被刪除版本號要麼沒有被定義,要麼大於事務的版本號:行的刪除版本號如沒被定義,說明行沒有被刪除過;如刪除
版本號>當前事務的版本號,說明該行的是被該事務的後面啟動事務刪除過(接著看下去..)
2)insert
對新插入的行,行的更新版本被修改為該事務的版本號
3)delete
對於刪除,innodb直接把該行的被刪除版本號設定為當前事務版本號,相當於標記刪除,不是實際刪除
4)update
在更新行的時候,innodb會把原來的行復制一份到回滾端的表空間中,若成功,並把當前事務的版本號作為該行
的更新版本號,否則rollback;

mvcc優缺點:
在讀取資料時,innodb幾乎不用獲取任何鎖,在每個查詢通過版本檢查,只獲取需要的資料版本,提高系統併發度
缺點:為了實現多版本,innodb必須對每行增加相應欄位來儲存版本資訊,同時需要維護每一行的版本資訊,而且
在檢索行的時候,需要進行版本的比較,因而減低了查詢效率;innodb還需要定期清理不再需要的行版本,及時回收
空間,這也增加開銷;

innodb支援事務隔離級別:
1)read uncommitted: (讀沒有提交的資料),無法避免髒讀;
2)read committed: (只能讀提交的資料),其他事務對資料庫的修改,只能已提交,其修改的結果可以看見,與這2個事務
開始的先後順序無關,這個級別避免髒讀,無法實現可重複讀,可能會產生幻讀
不可重複讀:t1:讀取一行 t2:再讀取這行時,可能被修改了,看不到啦
幻讀:t1:讀取有一行,t2:再讀取相同資料時,比t1時間多了資料
3)repeatable read:(可重複讀),只能讀取在它開始之前提交事務對資料庫的修改,在它開始之後,所有其他事務對資料庫
的修改對它來說均不可見.

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/26855487/viewspace-765514/,如需轉載,請註明出處,否則將追究法律責任。

相關文章