InnoDB併發事務

​目錄

 

---

1.行鎖：索引加鎖

2.意向鎖

3.間隙鎖

4.MVCC機制

 

 

行鎖

---

InnoDB經過多版本併發控制MVCC來支持事務

 

InnoDB的設計是爲了在處理大數據量的時候獲得最好的性能。InnoDB存儲引擎維護了一個它本身的緩衝區，用來存儲數據和索引。InnoDB將表和索引存儲在一個表空間中，這個表空間可能由不一樣的文件組成。而MyISAM存儲引擎的表中每一個表都存在一個獨立的文件裏面。

 

InnoDB事務模型是將傳統的兩階段封鎖協議同多版本數據庫特性相結合。它採用加行級鎖和查詢不加鎖。

 

InnoDB行鎖是經過給索引上的索引項加鎖來實現的，這一點MySQL與Oracle不一樣，後者是經過在數據塊中對相應數據行加鎖來實現的。

InnoDB這種行鎖實現特色意味着：只有經過索引條件檢索數據，InnoDB才使用行級鎖，不然，InnoDB將使用表鎖。

 

很顯然，在使用範圍條件檢索並鎖定記錄時，InnoDB這種加鎖機制會阻塞符合條件範圍內鍵值的併發插入，這每每會形成嚴重的鎖等待。所以，在實際應用開發中，尤爲是併發插入比較多的應用，咱們要儘可能優化業務邏輯，儘可能使用相等條件來訪問更新數據，避免使用範圍條件。

 

 

 

意向鎖

---

InnoDB支持多種上鎖粒度，它容許同時加行鎖和表鎖。爲了支持多粒度鎖，引入了一個新的鎖，意向鎖。意向鎖是加在表上的鎖。意向鎖就是代表某個事務以後要對這個表上的某個行加該類型的鎖。

       共享意向鎖IS，代表事務T將要在表T的某些行上加S鎖。

       排他意向鎖IX，代表事務T將要在表T的某些行上加X鎖

 

意向鎖協議是：

       在某個事務請求行上的S鎖以前，它必須先獲得該行所在表的IS鎖或更強的鎖。

在某個事務請求行上的X鎖以前，它必須先獲得該行所在表的IX鎖。

 

 

一致性非上鎖讀

---

       InnoDB使用多版本的方式來控制一致性讀，也就是說，給某個查詢在該時刻的一個數據庫的快照。這個查詢能夠看到這個時刻之前由其它事務提交的操做，而看不到以後作的改變或還未提交的改變。這個規則的惟一例外就是，事務能夠看到本事務以前所作的還未提交的操做。

       這個規則致使了下面的異常：若是你更新了某個表裏面的行，使用SELECT將能夠看見最新更新的行和老版本的行。若是其它事務同時更新相同的表，那麼你就可能看到根本不可能在數據庫中存在的狀態。

       若是在某人的REPEATABLE READ隔離級別下的話，全部同一事物的全部一致性讀都是讀的第一次查詢時創建的快照。若是想獲得最新的快照的話，那麼須要提交當前的事務，而後再開始新的查詢。

       注意：DROP TABLE 和ALTER TABLE語句不使用一致性讀。由於DROP TABLE的話，MYSQL不能使用已經刪除了的表。而ALTER TABLE的時候，MYSQL是將原來的表複製一份，而後刪除掉原來的表。

 

 

 

間隙鎖

---

Next-Key Locking：避免幻象

      當咱們用範圍條件而不是相等條件檢索數據，並請求共享或排他鎖時，InnoDB會給符合條件的已有數據記錄的 索引項加鎖；對於鍵值在條件範圍內但並不存在的記錄，叫作「間隙（GAP)」，InnoDB也會對這個「間隙」加鎖，這種鎖機制就是所謂的間隙鎖 （Next-Key鎖） 

        在行級鎖中，InnoDB使用一種稱爲next-key locking的算法。當檢索表的一個索引的時候，它對遇到的索引記錄加S或X鎖。所以行級鎖其實是索引記錄鎖。

       InnoDB在索引記錄上加鎖的時候也影響了索引記錄前的‘gap’。若是一個用戶擁有索引上某個記錄R的S或X鎖，另外一個用戶不能立刻在記錄R前插入一個新的索引記錄。這樣就能夠避免幻象的出現。

 

Next-key lock是Record lock與Gap lock相結合後的鎖。Next-key首先會使用Gap lock鎖定範圍，而後使用Record lock鎖定具體的行。這是REPEATABLE-READ隔離級別的默認處理方式。

 

 

MVCC實現機制

---

再也不單純的使用行鎖來進行數據庫的併發控制,取而代之的是,把數據庫的行鎖與行的多個版本結合起來,只須要很小的開銷,就能夠實現非鎖定讀,從而大大提升數據庫系統的併發性能。

 

爲了實現mvcc, innodb對每一行都加上了兩個隱含的列,其中一列存儲行被更新的」時間」,另一列存儲行被刪除的」時間」. 可是innodb存儲的並非絕對的時間,而是與時間對應的數據庫系統的版本號。

 

每當一個事務開始的時候,innodb都會給這個事務分配一個遞增的版本號,因此版本號也能夠被認爲是事務號.對於每個」查詢」語句,innodb都會把這個查詢語句的版本號同這個查詢語句遇到的行的版本號進行對比,而後結合不一樣的事務隔離等級,來決定是否返回該行.

 

 

mvcc優缺點

---

在讀取數據時,innodb幾乎不用獲取任何鎖,在每一個查詢經過版本檢查,只獲取須要的數據版本,提升系統併發度

缺點:爲了實現多版本,innodb必須對每行增長相應字段來存儲版本信息,同時須要維護每一行的版本信息,並且

在檢索行的時候,須要進行版本的比較,於是減低了查詢效率;innodb還須要按期清理再也不須要的行版本,及時回收

空間,這也增長開銷;

 

資料

---

MySQL加鎖處理分析：http://hedengcheng.com/?p=771