《InnoDB行鎖，如何鎖住一條不存在的記錄?》埋了一個(gè)坑，沒(méi)想到評(píng)論反響劇烈，大家都希望深挖下去。原計(jì)劃寫(xiě)寫(xiě)InnoDB的鎖結(jié)束這個(gè)case，既然呼聲這么高，干脆全盤(pán)系統(tǒng)性的寫(xiě)寫(xiě)InnoDB的并發(fā)控制，鎖，事務(wù)模型好了。

體系相對(duì)宏大，一篇肯定寫(xiě)不完，容我娓娓道來(lái)，通俗地說(shuō)清楚來(lái)龍去脈。

[[241518]]

一、并發(fā)控制

(1) 為啥要進(jìn)行并發(fā)控制?

并發(fā)的任務(wù)對(duì)同一個(gè)臨界資源進(jìn)行操作，如果不采取措施，可能導(dǎo)致不一致，故必須進(jìn)行并發(fā)控制(Concurrency Control)。

(2) 技術(shù)上，通常如何進(jìn)行并發(fā)控制?

通過(guò)并發(fā)控制保證數(shù)據(jù)一致性的常見(jiàn)手段有：

• 鎖(Locking)
• 數(shù)據(jù)多版本(Multi Versioning)

二、鎖

(1) 如何使用普通鎖保證一致性?

普通鎖，被使用最多：

• 操作數(shù)據(jù)前，鎖住，實(shí)施互斥，不允許其他的并發(fā)任務(wù)操作;
• 操作完成后，釋放鎖，讓其他任務(wù)執(zhí)行;

如此這般，來(lái)保證一致性。

(2) 普通鎖存在什么問(wèn)題?

簡(jiǎn)單的鎖住太過(guò)粗暴，連“讀任務(wù)”也無(wú)法并行，任務(wù)執(zhí)行過(guò)程本質(zhì)上是串行的。

于是出現(xiàn)了共享鎖與排他鎖：

• 共享鎖(Share Locks，記為S鎖)，讀取數(shù)據(jù)時(shí)加S鎖
• 排他鎖(eXclusive Locks，記為X鎖)，修改數(shù)據(jù)時(shí)加X(jué)鎖

共享鎖與排他鎖的玩法是：

• 共享鎖之間不互斥，簡(jiǎn)記為：讀讀可以并行
• 排他鎖與任何鎖互斥，簡(jiǎn)記為：寫(xiě)讀，寫(xiě)寫(xiě)不可以并行

可以看到，一旦寫(xiě)數(shù)據(jù)的任務(wù)沒(méi)有完成，數(shù)據(jù)是不能被其他任務(wù)讀取的，這對(duì)并發(fā)度有較大的影響。

畫(huà)外音：對(duì)應(yīng)到數(shù)據(jù)庫(kù)，可以理解為，寫(xiě)事務(wù)沒(méi)有提交，讀相關(guān)數(shù)據(jù)的select也會(huì)被阻塞。

(3) 有沒(méi)有可能，進(jìn)一步提高并發(fā)呢?

即使寫(xiě)任務(wù)沒(méi)有完成，其他讀任務(wù)也可能并發(fā)，這就引出了數(shù)據(jù)多版本。

三、數(shù)據(jù)多版本

數(shù)據(jù)多版本是一種能夠進(jìn)一步提高并發(fā)的方法，它的核心原理是：

• 寫(xiě)任務(wù)發(fā)生時(shí)，將數(shù)據(jù)克隆一份，以版本號(hào)區(qū)分;
• 寫(xiě)任務(wù)操作新克隆的數(shù)據(jù)，直至提交;
• 并發(fā)讀任務(wù)可以繼續(xù)讀取舊版本的數(shù)據(jù)，不至于阻塞;

如上圖：

• 最開(kāi)始數(shù)據(jù)的版本是V0;
• T1時(shí)刻發(fā)起了一個(gè)寫(xiě)任務(wù)，這是把數(shù)據(jù)clone了一份，進(jìn)行修改，版本變?yōu)閂1，但任務(wù)還未完成;
• T2時(shí)刻并發(fā)了一個(gè)讀任務(wù)，依然可以讀V0版本的數(shù)據(jù);
• T3時(shí)刻又并發(fā)了一個(gè)讀任務(wù)，依然不會(huì)阻塞;

可以看到，數(shù)據(jù)多版本，通過(guò)“讀取舊版本數(shù)據(jù)”能夠極大提高任務(wù)的并發(fā)度。

提高并發(fā)的演進(jìn)思路，就在如此：

• 普通鎖，本質(zhì)是串行執(zhí)行
• 讀寫(xiě)鎖，可以實(shí)現(xiàn)讀讀并發(fā)
• 數(shù)據(jù)多版本，可以實(shí)現(xiàn)讀寫(xiě)并發(fā)

畫(huà)外音：這個(gè)思路，比整篇文章的其他技術(shù)細(xì)節(jié)更重要，希望大家牢記。

好，對(duì)應(yīng)到InnoDB上，具體是怎么玩的呢?

四、redo, undo,回滾段

在進(jìn)一步介紹InnoDB如何使用“讀取舊版本數(shù)據(jù)”極大提高任務(wù)的并發(fā)度之前，有必要先介紹下redo日志，undo日志，回滾段(rollback segment)。

(1) 為什么要有redo日志?

數(shù)據(jù)庫(kù)事務(wù)提交后，必須將更新后的數(shù)據(jù)刷到磁盤(pán)上，以保證ACID特性。磁盤(pán)隨機(jī)寫(xiě)性能較低，如果每次都刷盤(pán)，會(huì)極大影響數(shù)據(jù)庫(kù)的吞吐量。

優(yōu)化方式是，將修改行為先寫(xiě)到redo日志里(此時(shí)變成了順序?qū)?，再定期將數(shù)據(jù)刷到磁盤(pán)上，這樣能極大提高性能。

畫(huà)外音：這里的架構(gòu)設(shè)計(jì)方法是，隨機(jī)寫(xiě)優(yōu)化為順序?qū)?，思路更重要?/p>

假如某一時(shí)刻，數(shù)據(jù)庫(kù)崩潰，還沒(méi)來(lái)得及刷盤(pán)的數(shù)據(jù)，在數(shù)據(jù)庫(kù)重啟后，會(huì)重做redo日志里的內(nèi)容，以保證已提交事務(wù)對(duì)數(shù)據(jù)產(chǎn)生的影響都刷到磁盤(pán)上。

一句話，redo日志用于保障，已提交事務(wù)的ACID特性。

(2) 為什么要有undo日志?

數(shù)據(jù)庫(kù)事務(wù)未提交時(shí)，會(huì)將事務(wù)修改數(shù)據(jù)的鏡像(即修改前的舊版本)存放到undo日志里，當(dāng)事務(wù)回滾時(shí)，或者數(shù)據(jù)庫(kù)奔潰時(shí)，可以利用undo日志，即舊版本數(shù)據(jù)，撤銷未提交事務(wù)對(duì)數(shù)據(jù)庫(kù)產(chǎn)生的影響。

畫(huà)外音：更細(xì)節(jié)的，

• 對(duì)于insert操作，undo日志記錄新數(shù)據(jù)的PK(ROW_ID)，回滾時(shí)直接刪除;
• 對(duì)于delete/update操作，undo日志記錄舊數(shù)據(jù)row，回滾時(shí)直接恢復(fù);

他們分別存放在不同的buffer里。

一句話，undo日志用于保障，未提交事務(wù)不會(huì)對(duì)數(shù)據(jù)庫(kù)的ACID特性產(chǎn)生影響。

(3) 什么是回滾段?

存儲(chǔ)undo日志的地方，是回滾段。

undo日志和回滾段和InnoDB的MVCC密切相關(guān)，這里舉個(gè)例子展開(kāi)說(shuō)明一下。

栗子：

t(id PK, name) 

數(shù)據(jù)為：

• shenjian
• zhangsan
• lisi

此時(shí)沒(méi)有事務(wù)未提交，故回滾段是空的。

接著啟動(dòng)了一個(gè)事務(wù)：

start trx; 
delete (1, shenjian); 
update set(3, lisi) to (3, xxx); 
insert (4, wangwu) 

并且事務(wù)處于未提交的狀態(tài)。

可以看到：

• 被刪除前的(1, shenjian)作為舊版本數(shù)據(jù)，進(jìn)入了回滾段;
• 被修改前的(3, lisi)作為舊版本數(shù)據(jù)，進(jìn)入了回滾段;
• 被插入的數(shù)據(jù)，PK(4)進(jìn)入了回滾段;

接下來(lái)，假如事務(wù)rollback，此時(shí)可以通過(guò)回滾段里的undo日志回滾。

畫(huà)外音：假設(shè)事務(wù)提交，回滾段里的undo日志可以刪除。

可以看到：

• 被刪除的舊數(shù)據(jù)恢復(fù)了;
• 被修改的舊數(shù)據(jù)也恢復(fù)了;
• 被插入的數(shù)據(jù)，刪除了;

事務(wù)回滾成功，一切如故。

四、InnoDB是基于多版本并發(fā)控制的存儲(chǔ)引擎

《大數(shù)據(jù)量，高并發(fā)量的互聯(lián)網(wǎng)業(yè)務(wù)，一定要使用InnoDB》提到，InnoDB是高并發(fā)互聯(lián)網(wǎng)場(chǎng)景最為推薦的存儲(chǔ)引擎，根本原因，就是其多版本并發(fā)控制(Multi Version Concurrency Control, MVCC)。行鎖，并發(fā)，事務(wù)回滾等多種特性都和MVCC相關(guān)。

MVCC就是通過(guò)“讀取舊版本數(shù)據(jù)”來(lái)降低并發(fā)事務(wù)的鎖沖突，提高任務(wù)的并發(fā)度。

(1) 核心問(wèn)題：舊版本數(shù)據(jù)存儲(chǔ)在哪里?

存儲(chǔ)舊版本數(shù)據(jù)，對(duì)MySQL和InnoDB原有架構(gòu)是否有巨大沖擊?

通過(guò)上文undo日志和回滾段的鋪墊，這兩個(gè)問(wèn)題就非常好回答了：

• 舊版本數(shù)據(jù)存儲(chǔ)在回滾段里;
• 對(duì)MySQL和InnoDB原有架構(gòu)體系沖擊不大;

InnoDB的內(nèi)核，會(huì)對(duì)所有row數(shù)據(jù)增加三個(gè)內(nèi)部屬性：

• DB_TRX_ID，6字節(jié)，記錄每一行最近一次修改它的事務(wù)ID;
• DB_ROLL_PTR，7字節(jié)，記錄指向回滾段undo日志的指針;
• DB_ROW_ID，6字節(jié)，單調(diào)遞增的行ID;

(2) InnoDB為何能夠做到這么高的并發(fā)?

回滾段里的數(shù)據(jù)，其實(shí)是歷史數(shù)據(jù)的快照(snapshot)，這些數(shù)據(jù)是不會(huì)被修改，select可以肆無(wú)忌憚的并發(fā)讀取他們。

快照讀(Snapshot Read)，這種一致性不加鎖的讀(Consistent Nonlocking Read)，就是InnoDB并發(fā)如此之高的核心原因之一。

這里的一致性是指，事務(wù)讀取到的數(shù)據(jù)，要么是事務(wù)開(kāi)始前就已經(jīng)存在的數(shù)據(jù)(當(dāng)然，是其他已提交事務(wù)產(chǎn)生的)，要么是事務(wù)自身插入或者修改的數(shù)據(jù)。

(3) 什么樣的select是快照讀?

除非顯示加鎖，普通的select語(yǔ)句都是快照讀，例如：

select * from t where id>2 

這里的顯示加鎖，非快照讀是指：

select * from t where id>2 lock in share mode 
select * from t where id>2 for update 

問(wèn)題來(lái)了，這些顯示加鎖的讀，是什么讀?會(huì)加什么鎖?和事務(wù)的隔離級(jí)別又有什么關(guān)系?

本節(jié)的內(nèi)容已經(jīng)夠多了，且聽(tīng)下回分解。

五、總結(jié)

• 常見(jiàn)并發(fā)控制保證數(shù)據(jù)一致性的方法有鎖，數(shù)據(jù)多版本;
• 普通鎖串行，讀寫(xiě)鎖讀讀并行，數(shù)據(jù)多版本讀寫(xiě)并行;
• redo日志保證已提交事務(wù)的ACID特性，設(shè)計(jì)思路是，通過(guò)順序?qū)懱娲S機(jī)寫(xiě)，提高并發(fā);
• undo日志用來(lái)回滾未提交的事務(wù)，它存儲(chǔ)在回滾段里;
• InnoDB是基于MVCC的存儲(chǔ)引擎，它利用了存儲(chǔ)在回滾段里的undo日志，即數(shù)據(jù)的舊版本，提高并發(fā);
• InnoDB之所以并發(fā)高，快照讀不加鎖;
• InnoDB所有普通select都是快照讀;

畫(huà)外音：本文的知識(shí)點(diǎn)均基于MySQL5.6。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文