InnoDB，為何併發如此之高？
一、併發控制
為啥要進行併發控制？
併發的任務對同一個臨界資源進行操作，如果不採取措施，可能導致不一致，故必須進行併發控制（Concurrency Control）。
技術上，通常如何進行併發控制？
通過併發控制保證資料一致性的常見手段有：
-
鎖（Locking）
-
資料多版本（Multi Versioning）
二、鎖
如何使用普通鎖保證一致性？
普通鎖，被使用最多：
(1)操作資料前，鎖住，實施互斥，不允許其他的併發任務操作；
(2)操作完成後，釋放鎖，讓其他任務執行；
如此這般，來保證一致性。
普通鎖存在什麼問題？
簡單的鎖住太過粗暴，連“讀任務”也無法並行，任務執行過程本質上是序列的。
於是出現了共享鎖與排他鎖：
-
共享鎖（Share Locks，記為S鎖），讀取資料時加S鎖
-
排他鎖（eXclusive Locks，記為X鎖），修改資料時加X鎖
共享鎖與排他鎖的玩法是：
-
共享鎖之間不互斥，簡記為：讀讀可以並行
-
排他鎖與任何鎖互斥，簡記為：寫讀，寫寫不可以並行
可以看到，一旦寫資料的任務沒有完成，資料是不能被其他任務讀取的，這對併發度有較大的影響。
畫外音：對應到資料庫，可以理解為，寫事務沒有提交，讀相關資料的select也會被阻塞。
有沒有可能，進一步提高併發呢？
即使寫任務沒有完成，其他讀任務也可能併發，這就引出了資料多版本。
三、資料多版本
資料多版本是一種能夠進一步提高併發的方法，它的核心原理是：
（1）寫任務發生時，將資料克隆一份，以版本號區分；
（2）寫任務操作新克隆的資料，直至提交；
（3）併發讀任務可以繼續讀取舊版本的資料，不至於阻塞；
如上圖：
-
最開始資料的版本是V0；
-
T1時刻發起了一個寫任務，這是把資料clone了一份，進行修改，版本變為V1，但任務還未完成；
-
T2時刻併發了一個讀任務，依然可以讀V0版本的資料；
-
T3時刻又併發了一個讀任務，依然不會阻塞；
可以看到，資料多版本，通過“讀取舊版本資料”能夠極大提高任務的併發度。
提高併發的演進思路，就在如此：
普通鎖，本質是序列執行
讀寫鎖，可以實現讀讀併發
資料多版本，可以實現讀寫併發
畫外音：這個思路，比整篇文章的其他技術細節更重要，希望大家牢記。
好，對應到InnoDB上，具體是怎麼玩的呢？
四、redo, undo,回滾段
在進一步介紹InnoDB如何使用“讀取舊版本資料”極大提高任務的併發度之前，有必要先介紹下redo日誌，undo日誌，回滾段（rollback segment）。
為什麼要有redo日誌？
資料庫事務提交後，必須將更新後的資料刷到磁碟上，以保證ACID特性。磁碟隨機寫效能較低，如果每次都刷盤，會極大影響資料庫的吞吐量。
優化方式是，將修改行為先寫到redo日誌裡（此時變成了順序寫），再定期將資料刷到磁碟上，這樣能極大提高效能。
畫外音：這裡的架構設計方法是，隨機寫優化為順序寫，思路更重要。
假如某一時刻，資料庫崩潰，還沒來得及刷盤的資料，在資料庫重啟後，會重做redo日誌裡的內容，以保證已提交事務對資料產生的影響都刷到磁碟上。
一句話，redo日誌用於保障，已提交事務的ACID特性。
為什麼要有undo日誌？
資料庫事務未提交時，會將事務修改資料的映象（即修改前的舊版本）存放到undo日誌裡，當事務回滾時，或者資料庫奔潰時，可以利用undo日誌，即舊版本資料，撤銷未提交事務對資料庫產生的影響。
畫外音：更細節的， 對於insert操作，undo日誌記錄新資料的PK(ROW_ID)，回滾時直接刪除； 對於delete/update操作，undo日誌記錄舊資料row，回滾時直接恢復； 他們分別存放在不同的buffer裡。
一句話，undo日誌用於保障，未提交事務不會對資料庫的ACID特性產生影響。
什麼是回滾段？
儲存undo日誌的地方，是回滾段。
undo日誌和回滾段和InnoDB的MVCC密切相關，這裡舉個例子展開說明一下。
栗子：
t(id PK, name);
資料為：
1, shenjian
2, zhangsan
3, lisi
此時沒有事務未提交，故回滾段是空的。
接著啟動了一個事務：
start trx;
delete (1, shenjian);
update set(3, lisi) to (3, xxx);
insert (4, wangwu);
並且事務處於未提交的狀態。
可以看到：
(1)被刪除前的(1, shenjian)作為舊版本資料，進入了回滾段；
(2)被修改前的(3, lisi)作為舊版本資料，進入了回滾段；
(3)被插入的資料，PK(4)進入了回滾段；
接下來，假如事務rollback，此時可以通過回滾段裡的undo日誌回滾。
畫外音：假設事務提交，回滾段裡的undo日誌可以刪除。
可以看到：
(1)被刪除的舊資料恢復了；
(2)被修改的舊資料也恢復了；
(3)被插入的資料，刪除了；
事務回滾成功，一切如故。
四、InnoDB是基於多版本併發控制的儲存引擎
InnoDB是高併發網際網路場景最為推薦的儲存引擎，根本原因，就是其多版本併發控制（Multi Version Concurrency Control, MVCC）。行鎖，併發，事務回滾等多種特性都和MVCC相關。
MVCC就是通過“讀取舊版本資料”來降低併發事務的鎖衝突，提高任務的併發度。
核心問題：
-
舊版本資料儲存在哪裡？ 答：舊版本資料儲存在回滾段裡；
-
儲存舊版本資料，對MySQL和InnoDB原有架構是否有巨大沖擊？ 答：對MySQL和InnoDB原有架構體系衝擊不大；
InnoDB的核心，會對所有row資料增加三個內部屬性： (1)DB_TRX_ID，6位元組，記錄每一行最近一次修改它的事務ID； (2)DB_ROLL_PTR，7位元組，記錄指向回滾段undo日誌的指標； (3)DB_ROW_ID，6位元組，單調遞增的行ID；
- InnoDB為何能夠做到這麼高的併發？
回滾段裡的資料，其實是歷史資料的快照（snapshot），這些資料是不會被修改，select可以肆無忌憚的併發讀取他們。
快照讀（Snapshot Read），這種一致性不加鎖的讀（Consistent Nonlocking Read），就是InnoDB併發如此之高的核心原因之一。
這裡的一致性是指，事務讀取到的資料，要麼是事務開始前就已經存在的資料（當然，是其他已提交事務產生的），要麼是事務自身插入或者修改的資料。
- 什麼樣的select是快照讀？
除非顯示加鎖，普通的select語句都是快照讀，例如：
select * from t where id>2;
這裡的顯示加鎖，非快照讀是指：
select * from t where id>2 lock in share mode;
select * from t where id>2 for update;
問題來了，這些顯示加鎖的讀，是什麼讀？會加什麼鎖？和事務的隔離級別又有什麼關係？
本節的內容已經夠多了，且聽下回分解。
總結
(1)常見併發控制保證資料一致性的方法有鎖，資料多版本；
(2)普通鎖序列，讀寫鎖讀讀並行，資料多版本讀寫並行；
(3)redo日誌保證已提交事務的ACID特性，設計思路是，通過順序寫替代隨機寫，提高併發；
(4)undo日誌用來回滾未提交的事務，它儲存在回滾段裡；
(5)InnoDB是基於MVCC的儲存引擎，它利用了儲存在回滾段裡的undo日誌，即資料的舊版本，提高併發；
(6)InnoDB之所以併發高，快照讀不加鎖；
(7)InnoDB所有普通select都是快照讀；
畫外音：本文的知識點均基於MySQL5.6。