建站
咨詢
售后
建站咨詢
新聞中心
《InnoDB行鎖，如何鎖住一條不存在的記錄?》埋了一個坑，沒想到評論反響劇烈，大家都希望深挖下去。原計(jì)劃寫寫InnoDB的鎖結(jié)束這個case，既然呼聲這么高，干脆全盤系統(tǒng)性的寫寫InnoDB的并發(fā)控制，鎖，事務(wù)模型好了。
雞西ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！
體系相對宏大，一篇肯定寫不完，容我娓娓道來，通俗地說清楚來龍去脈。
一、并發(fā)控制
(1) 為啥要進(jìn)行并發(fā)控制?
并發(fā)的任務(wù)對同一個臨界資源進(jìn)行操作，如果不采取措施，可能導(dǎo)致不一致，故必須進(jìn)行并發(fā)控制(Concurrency Control)。
(2) 技術(shù)上，通常如何進(jìn)行并發(fā)控制?
通過并發(fā)控制保證數(shù)據(jù)一致性的常見手段有：
- 鎖(Locking)
- 數(shù)據(jù)多版本(Multi Versioning)
二、鎖
(1) 如何使用普通鎖保證一致性?
普通鎖，被使用最多：
- 操作數(shù)據(jù)前，鎖住，實(shí)施互斥，不允許其他的并發(fā)任務(wù)操作;
- 操作完成后，釋放鎖，讓其他任務(wù)執(zhí)行;
如此這般，來保證一致性。
(2) 普通鎖存在什么問題?
簡單的鎖住太過粗暴，連“讀任務(wù)”也無法并行，任務(wù)執(zhí)行過程本質(zhì)上是串行的。
于是出現(xiàn)了共享鎖與排他鎖：
- 共享鎖(Share Locks，記為S鎖)，讀取數(shù)據(jù)時加S鎖
- 排他鎖(eXclusive Locks，記為X鎖)，修改數(shù)據(jù)時加X鎖
共享鎖與排他鎖的玩法是：
- 共享鎖之間不互斥，簡記為：讀讀可以并行
- 排他鎖與任何鎖互斥，簡記為：寫讀，寫寫不可以并行
可以看到，一旦寫數(shù)據(jù)的任務(wù)沒有完成，數(shù)據(jù)是不能被其他任務(wù)讀取的，這對并發(fā)度有較大的影響。
畫外音：對應(yīng)到數(shù)據(jù)庫，可以理解為，寫事務(wù)沒有提交，讀相關(guān)數(shù)據(jù)的select也會被阻塞。
(3) 有沒有可能，進(jìn)一步提高并發(fā)呢?
即使寫任務(wù)沒有完成，其他讀任務(wù)也可能并發(fā)，這就引出了數(shù)據(jù)多版本。
三、數(shù)據(jù)多版本
數(shù)據(jù)多版本是一種能夠進(jìn)一步提高并發(fā)的方法，它的核心原理是：
- 寫任務(wù)發(fā)生時，將數(shù)據(jù)克隆一份，以版本號區(qū)分;
- 寫任務(wù)操作新克隆的數(shù)據(jù)，直至提交;
- 并發(fā)讀任務(wù)可以繼續(xù)讀取舊版本的數(shù)據(jù)，不至于阻塞;
如上圖：
- 最開始數(shù)據(jù)的版本是V0;
- T1時刻發(fā)起了一個寫任務(wù)，這是把數(shù)據(jù)clone了一份，進(jìn)行修改，版本變?yōu)閂1，但任務(wù)還未完成;
- T2時刻并發(fā)了一個讀任務(wù)，依然可以讀V0版本的數(shù)據(jù);
- T3時刻又并發(fā)了一個讀任務(wù)，依然不會阻塞;
可以看到，數(shù)據(jù)多版本，通過“讀取舊版本數(shù)據(jù)”能夠極大提高任務(wù)的并發(fā)度。
提高并發(fā)的演進(jìn)思路，就在如此：
- 普通鎖，本質(zhì)是串行執(zhí)行
- 讀寫鎖，可以實(shí)現(xiàn)讀讀并發(fā)
- 數(shù)據(jù)多版本，可以實(shí)現(xiàn)讀寫并發(fā)
畫外音：這個思路，比整篇文章的其他技術(shù)細(xì)節(jié)更重要，希望大家牢記。
好，對應(yīng)到InnoDB上，具體是怎么玩的呢?
四、redo, undo,回滾段
在進(jìn)一步介紹InnoDB如何使用“讀取舊版本數(shù)據(jù)”極大提高任務(wù)的并發(fā)度之前，有必要先介紹下redo日志，undo日志，回滾段(rollback segment)。
(1) 為什么要有redo日志?
數(shù)據(jù)庫事務(wù)提交后，必須將更新后的數(shù)據(jù)刷到磁盤上，以保證ACID特性。磁盤隨機(jī)寫性能較低，如果每次都刷盤，會極大影響數(shù)據(jù)庫的吞吐量。
優(yōu)化方式是，將修改行為先寫到redo日志里(此時變成了順序?qū)?，再定期將數(shù)據(jù)刷到磁盤上，這樣能極大提高性能。
畫外音：這里的架構(gòu)設(shè)計(jì)方法是，隨機(jī)寫優(yōu)化為順序?qū)懀悸犯匾?/p>
假如某一時刻，數(shù)據(jù)庫崩潰，還沒來得及刷盤的數(shù)據(jù)，在數(shù)據(jù)庫重啟后，會重做redo日志里的內(nèi)容，以保證已提交事務(wù)對數(shù)據(jù)產(chǎn)生的影響都刷到磁盤上。
一句話，redo日志用于保障，已提交事務(wù)的ACID特性。
(2) 為什么要有undo日志?
數(shù)據(jù)庫事務(wù)未提交時，會將事務(wù)修改數(shù)據(jù)的鏡像(即修改前的舊版本)存放到undo日志里，當(dāng)事務(wù)回滾時，或者數(shù)據(jù)庫奔潰時，可以利用undo日志，即舊版本數(shù)據(jù)，撤銷未提交事務(wù)對數(shù)據(jù)庫產(chǎn)生的影響。
畫外音：更細(xì)節(jié)的，
- 對于insert操作，undo日志記錄新數(shù)據(jù)的PK(ROW_ID)，回滾時直接刪除;
- 對于delete/update操作，undo日志記錄舊數(shù)據(jù)row，回滾時直接恢復(fù);
他們分別存放在不同的buffer里。
一句話，undo日志用于保障，未提交事務(wù)不會對數(shù)據(jù)庫的ACID特性產(chǎn)生影響。
(3) 什么是回滾段?
存儲undo日志的地方，是回滾段。
undo日志和回滾段和InnoDB的MVCC密切相關(guān)，這里舉個例子展開說明一下。
栗子：
- t(id PK, name)
數(shù)據(jù)為：
- shenjian
- zhangsan
- lisi
此時沒有事務(wù)未提交，故回滾段是空的。
接著啟動了一個事務(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)入了回滾段;
接下來，假如事務(wù)rollback，此時可以通過回滾段里的undo日志回滾。
畫外音：假設(shè)事務(wù)提交，回滾段里的undo日志可以刪除。
可以看到：
- 被刪除的舊數(shù)據(jù)恢復(fù)了;
- 被修改的舊數(shù)據(jù)也恢復(fù)了;
- 被插入的數(shù)據(jù)，刪除了;
事務(wù)回滾成功，一切如故。
四、InnoDB是基于多版本并發(fā)控制的存儲引擎
《大數(shù)據(jù)量，高并發(fā)量的互聯(lián)網(wǎng)業(yè)務(wù)，一定要使用InnoDB》提到，InnoDB是高并發(fā)互聯(lián)網(wǎng)場景最為推薦的存儲引擎，根本原因，就是其多版本并發(fā)控制(Multi Version Concurrency Control, MVCC)。行鎖，并發(fā)，事務(wù)回滾等多種特性都和MVCC相關(guān)。
MVCC就是通過“讀取舊版本數(shù)據(jù)”來降低并發(fā)事務(wù)的鎖沖突，提高任務(wù)的并發(fā)度。
(1) 核心問題：舊版本數(shù)據(jù)存儲在哪里?
存儲舊版本數(shù)據(jù)，對MySQL和InnoDB原有架構(gòu)是否有巨大沖擊?
通過上文undo日志和回滾段的鋪墊，這兩個問題就非常好回答了：
- 舊版本數(shù)據(jù)存儲在回滾段里;
- 對MySQL和InnoDB原有架構(gòu)體系沖擊不大;
InnoDB的內(nèi)核，會對所有row數(shù)據(jù)增加三個內(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ù)是不會被修改，select可以肆無忌憚的并發(fā)讀取他們。
快照讀(Snapshot Read)，這種一致性不加鎖的讀(Consistent Nonlocking Read)，就是InnoDB并發(fā)如此之高的核心原因之一。
這里的一致性是指，事務(wù)讀取到的數(shù)據(jù)，要么是事務(wù)開始前就已經(jīng)存在的數(shù)據(jù)(當(dāng)然，是其他已提交事務(wù)產(chǎn)生的)，要么是事務(wù)自身插入或者修改的數(shù)據(jù)。
(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
問題來了，這些顯示加鎖的讀，是什么讀?會加什么鎖?和事務(wù)的隔離級別又有什么關(guān)系?
本節(jié)的內(nèi)容已經(jīng)夠多了，且聽下回分解。
五、總結(jié)
- 常見并發(fā)控制保證數(shù)據(jù)一致性的方法有鎖，數(shù)據(jù)多版本;
- 普通鎖串行，讀寫鎖讀讀并行，數(shù)據(jù)多版本讀寫并行;
- redo日志保證已提交事務(wù)的ACID特性，設(shè)計(jì)思路是，通過順序?qū)懱娲S機(jī)寫，提高并發(fā);
- undo日志用來回滾未提交的事務(wù)，它存儲在回滾段里;
- InnoDB是基于MVCC的存儲引擎，它利用了存儲在回滾段里的undo日志，即數(shù)據(jù)的舊版本，提高并發(fā);
- InnoDB之所以并發(fā)高，快照讀不加鎖;
- InnoDB所有普通select都是快照讀;
畫外音：本文的知識點(diǎn)均基于MySQL5.6。
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
網(wǎng)站欄目：InnoDB并發(fā)如此高，原因竟然在這？
分享鏈接：http://www.dlmjj.cn/article/dhchpoj.html
