InnoDB并發如此高，原因竟然在這？
《InnoDB行鎖，如何鎖住一條不存在的記錄?》埋了一個坑，沒想到評論反響劇烈，大家都希望深挖下去。原計劃寫寫InnoDB的鎖結束這個case，既然呼聲這么高，干脆全盤系統性的寫寫InnoDB的并發控制，鎖，事務模型好了。
體系相對宏大，一篇肯定寫不完，容我娓娓道來，通俗地說清楚來龍去脈。
一、并發控制
(1) 為啥要進行并發控制?
并發的任務對同一個臨界資源進行操作，如果不采取措施，可能導致不一致，故必須進行并發控制(Concurrency Control)。
(2) 技術上，通常如何進行并發控制?
通過并發控制保證數據一致性的常見手段有：
- 鎖(Locking)
- 數據多版本(Multi Versioning)
二、鎖
(1) 如何使用普通鎖保證一致性?
普通鎖，被使用最多：
- 操作數據前，鎖住，實施互斥，不允許其他的并發任務操作;
- 操作完成后，釋放鎖，讓其他任務執行;
如此這般，來保證一致性。
(2) 普通鎖存在什么問題?
簡單的鎖住太過粗暴，連“讀任務”也無法并行，任務執行過程本質上是串行的。
于是出現了共享鎖與排他鎖：
- 共享鎖(Share Locks，記為S鎖)，讀取數據時加S鎖
- 排他鎖(eXclusive Locks，記為X鎖)，修改數據時加X鎖
共享鎖與排他鎖的玩法是：
- 共享鎖之間不互斥，簡記為：讀讀可以并行
- 排他鎖與任何鎖互斥，簡記為：寫讀，寫寫不可以并行
可以看到，一旦寫數據的任務沒有完成，數據是不能被其他任務讀取的，這對并發度有較大的影響。
畫外音：對應到數據庫，可以理解為，寫事務沒有提交，讀相關數據的select也會被阻塞。
(3) 有沒有可能，進一步提高并發呢?
即使寫任務沒有完成，其他讀任務也可能并發，這就引出了數據多版本。
三、數據多版本
數據多版本是一種能夠進一步提高并發的方法，它的核心原理是：
- 寫任務發生時，將數據克隆一份，以版本號區分;
- 寫任務操作新克隆的數據，直至提交;
- 并發讀任務可以繼續讀取舊版本的數據，不至于阻塞;
如上圖：
- 最開始數據的版本是V0;
- T1時刻發起了一個寫任務，這是把數據clone了一份，進行修改，版本變為V1，但任務還未完成;
- T2時刻并發了一個讀任務，依然可以讀V0版本的數據;
- T3時刻又并發了一個讀任務，依然不會阻塞;
可以看到，數據多版本，通過“讀取舊版本數據”能夠極大提高任務的并發度。
提高并發的演進思路，就在如此：
- 普通鎖，本質是串行執行
- 讀寫鎖，可以實現讀讀并發
- 數據多版本，可以實現讀寫并發
畫外音：這個思路，比整篇文章的其他技術細節更重要，希望大家牢記。
好，對應到InnoDB上，具體是怎么玩的呢?
四、redo, undo,回滾段
在進一步介紹InnoDB如何使用“讀取舊版本數據”極大提高任務的并發度之前，有必要先介紹下redo日志，undo日志，回滾段(rollback segment)。
(1) 為什么要有redo日志?
數據庫事務提交后，必須將更新后的數據刷到磁盤上，以保證ACID特性。磁盤隨機寫性能較低，如果每次都刷盤，會極大影響數據庫的吞吐量。
優化方式是，將修改行為先寫到redo日志里(此時變成了順序寫)，再定期將數據刷到磁盤上，這樣能極大提高性能。
畫外音：這里的架構設計方法是，隨機寫優化為順序寫，思路更重要。
假如某一時刻，數據庫崩潰，還沒來得及刷盤的數據，在數據庫重啟后，會重做redo日志里的內容，以保證已提交事務對數據產生的影響都刷到磁盤上。
一句話，redo日志用于保障，已提交事務的ACID特性。
(2) 為什么要有undo日志?
數據庫事務未提交時，會將事務修改數據的鏡像(即修改前的舊版本)存放到undo日志里，當事務回滾時，或者數據庫奔潰時，可以利用undo日志，即舊版本數據，撤銷未提交事務對數據庫產生的影響。
畫外音：更細節的，
- 對于insert操作，undo日志記錄新數據的PK(ROW_ID)，回滾時直接刪除;
- 對于delete/update操作，undo日志記錄舊數據row，回滾時直接恢復;
他們分別存放在不同的buffer里。
一句話，undo日志用于保障，未提交事務不會對數據庫的ACID特性產生影響。
(3) 什么是回滾段?
存儲undo日志的地方，是回滾段。
undo日志和回滾段和InnoDB的MVCC密切相關，這里舉個例子展開說明一下。
栗子：
- t(id PK, name)
數據為：
- shenjian
- zhangsan
- lisi
此時沒有事務未提交，故回滾段是空的。
接著啟動了一個事務：
- start trx;
- delete (1, shenjian);
- update set(3, lisi) to (3, xxx);
- insert (4, wangwu)
并且事務處于未提交的狀態。
可以看到：
- 被刪除前的(1, shenjian)作為舊版本數據，進入了回滾段;
- 被修改前的(3, lisi)作為舊版本數據，進入了回滾段;
- 被插入的數據，PK(4)進入了回滾段;
接下來，假如事務rollback，此時可以通過回滾段里的undo日志回滾。
畫外音：假設事務提交，回滾段里的undo日志可以刪除。
可以看到：
- 被刪除的舊數據恢復了;
- 被修改的舊數據也恢復了;
- 被插入的數據，刪除了;
事務回滾成功，一切如故。
四、InnoDB是基于多版本并發控制的存儲引擎
《大數據量，高并發量的互聯網業務，一定要使用InnoDB》提到，InnoDB是高并發互聯網場景最為推薦的存儲引擎，根本原因，就是其多版本并發控制(Multi Version Concurrency Control, MVCC)。行鎖，并發，事務回滾等多種特性都和MVCC相關。
MVCC就是通過“讀取舊版本數據”來降低并發事務的鎖沖突，提高任務的并發度。
(1) 核心問題：舊版本數據存儲在哪里?
存儲舊版本數據，對MySQL和InnoDB原有架構是否有巨大沖擊?
通過上文undo日志和回滾段的鋪墊，這兩個問題就非常好回答了：
- 舊版本數據存儲在回滾段里;
- 對MySQL和InnoDB原有架構體系沖擊不大;
InnoDB的內核，會對所有row數據增加三個內部屬性：
- DB_TRX_ID，6字節，記錄每一行最近一次修改它的事務ID;
- DB_ROLL_PTR，7字節，記錄指向回滾段undo日志的指針;
- DB_ROW_ID，6字節，單調遞增的行ID;
(2) InnoDB為何能夠做到這么高的并發?
回滾段里的數據，其實是歷史數據的快照(snapshot)，這些數據是不會被修改，select可以肆無忌憚的并發讀取他們。
快照讀(Snapshot Read)，這種一致性不加鎖的讀(Consistent Nonlocking Read)，就是InnoDB并發如此之高的核心原因之一。
這里的一致性是指，事務讀取到的數據，要么是事務開始前就已經存在的數據(當然，是其他已提交事務產生的)，要么是事務自身插入或者修改的數據。
(3) 什么樣的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
問題來了，這些顯示加鎖的讀，是什么讀?會加什么鎖?和事務的隔離級別又有什么關系?
本節的內容已經夠多了，且聽下回分解。
五、總結
- 常見并發控制保證數據一致性的方法有鎖，數據多版本;
- 普通鎖串行，讀寫鎖讀讀并行，數據多版本讀寫并行;
- redo日志保證已提交事務的ACID特性，設計思路是，通過順序寫替代隨機寫，提高并發;
- undo日志用來回滾未提交的事務，它存儲在回滾段里;
- InnoDB是基于MVCC的存儲引擎，它利用了存儲在回滾段里的undo日志，即數據的舊版本，提高并發;
- InnoDB之所以并發高，快照讀不加鎖;
- InnoDB所有普通select都是快照讀;
畫外音：本文的知識點均基于MySQL5.6。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
