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