眾所周知殖妇，事務和鎖是mysql中非常重要功能，同時也是面試的重點和難點破花。本文會詳細介紹事務和鎖的相關概念及其實現(xiàn)原理谦趣，相信大家看完之后，一定會對事務和鎖有更加深入的理解座每。
什么是事務
在維基百科中蔚润，對事務的定義是：事務是數據庫管理系統(tǒng)(DBMS)執(zhí)行過程中的一個邏輯單位，由一個有限的數據庫操作序列構成尺栖。
- 事務的四大特性
事務包含四大特性嫡纠，即原子性（Atomicity）、一致性（Consistency）延赌、隔離性（Isolation）和持久性（Durability）(ACID)除盏。
- 原子性（Atomicity） 原子性是指對數據庫的一系列操作，要么全部成功挫以，要么全部失敗者蠕，不可能出現(xiàn)部分成功的情況。以轉賬場景為例掐松，一個賬戶的余額減少踱侣，另一個賬戶的余額增加，這兩個操作一定是同時成功或者同時失敗的大磺。
- 一致性（Consistency） 一致性是指數據庫的完整性約束沒有被破壞抡句，在事務執(zhí)行前后都是合法的數據狀態(tài)。這里的一致可以表示數據庫自身的約束沒有被破壞杠愧，比如某些字段的唯一性約束待榔、字段長度約束等等；還可以表示各種實際場景下的業(yè)務約束流济，比如上面轉賬操作锐锣，一個賬戶減少的金額和另一個賬戶增加的金額一定是一樣的。
- 隔離性（Isolation） 隔離性指的是多個事務彼此之間是完全隔離绳瘟、互不干擾的雕憔。隔離性的最終目的也是為了保證一致性。
- 持久性（Durability） 持久性是指只要事務提交成功糖声，那么對數據庫做的修改就被永久保存下來了斤彼，不可能因為任何原因再回到原來的狀態(tài)分瘦。
- 事務的狀態(tài)
根據事務所處的不同階段，事務大致可以分為以下5個狀態(tài)：
- 活動的（active） 當事務對應的數據庫操作正在執(zhí)行過程中畅卓，則該事務處于
活動狀態(tài)。 - 部分提交的（partially committed） 當事務中的最后一個操作執(zhí)行完成蟋恬，但還未將變更刷新到磁盤時翁潘，則該事務處于
部分提交狀態(tài)。 - 失敗的（failed） 當事務處于
活動或者部分提交狀態(tài)時歼争，由于某些錯誤導致事務無法繼續(xù)執(zhí)行拜马，則事務處于失敗狀態(tài)。 - 中止的（aborted） 當事務處于
失敗狀態(tài)沐绒，且回滾操作執(zhí)行完畢俩莽，數據恢復到事務執(zhí)行之前的狀態(tài)時，則該事務處于中止狀態(tài)乔遮。 - 提交的（committed） 當事務處于
部分提交狀態(tài)扮超，并且將修改過的數據都同步到磁盤之后，此時該事務處于提交狀態(tài)蹋肮。
- 事務隔離級別
前面提到過出刷，事務必須具有隔離性。實現(xiàn)隔離性最簡單的方式就是不允許事務并發(fā)坯辩，每個事務都排隊執(zhí)行馁龟，但是這種方式性能實在太差了。為了兼顧事務的隔離性和性能漆魔，事務支持不同的隔離級別坷檩。
為了方便表述后續(xù)的內容，我們先建一張示例表hero改抡。
CREATE TABLE hero (
number INT,
name VARCHAR(100),
country varchar(100),
PRIMARY KEY (number)
) Engine=InnoDB CHARSET=utf8;
事務并發(fā)執(zhí)行遇到的問題
在事務并發(fā)執(zhí)行時矢炼，如果不進行任何控制，可能會出現(xiàn)以下4類問題：
- 臟寫（Dirty Write） 臟寫是指一個事務修改了其它事務未提交的數據阿纤。
如上圖裸删，Session A和Session B各開啟了一個事務，Session B中的事務先將number列為1的記錄的name列更新為'關羽'阵赠，然后Session A中的事務接著又把這條number列為1的記錄的name列更新為張飛涯塔。如果之后Session B中的事務進行了回滾，那么Session A中的更新也將不復存在清蚀，這種現(xiàn)象就稱之為臟寫匕荸。
- 臟讀（Dirty Read） 臟讀是指一個事務讀到了其它事務未提交的數據。
如上圖枷邪，Session A和Session B各開啟了一個事務榛搔，Session B中的事務先將number列為1的記錄的name列更新為'關羽'，然后Session A中的事務再去查詢這條number為1的記錄，如果讀到列name的值為'關羽'践惑，而Session B中的事務稍后進行了回滾腹泌，那么Session A中的事務相當于讀到了一個不存在的數據，這種現(xiàn)象就稱之為臟讀尔觉。
- 不可重復讀（Non-Repeatable Read） 不可重復讀指的是在一個事務執(zhí)行過程中凉袱，讀取到其它事務已提交的數據，導致兩次讀取的結果不一致侦铜。
如上圖专甩，我們在Session B中提交了幾個隱式事務(mysql會自動為增刪改語句加事務)，這些事務都修改了number列為1的記錄的列name的值钉稍，每次事務提交之后涤躲，如果Session A中的事務都可以查看到最新的值，這種現(xiàn)象也被稱之為不可重復讀贡未。
- 幻讀（Phantom） 幻讀是指的是在一個事務執(zhí)行過程中种樱，讀取到了其他事務新插入數據，導致兩次讀取的結果不一致俊卤。
如上圖缸托，Session A中的事務先根據條件number > 0這個條件查詢表hero，得到了name列值為'劉備'的記錄瘾蛋；之后Session B中提交了一個隱式事務俐镐，該事務向表hero中插入了一條新記錄；之后Session A中的事務再根據相同的條件number > 0查詢表hero哺哼，得到的結果集中包含Session B中的事務新插入的那條記錄佩抹，這種現(xiàn)象也被稱之為幻讀。
不可重復讀和幻讀的區(qū)別在于不可重復讀是讀到的是其他事務修改或者刪除的數據取董，而幻讀讀到的是其它事務新插入的數據棍苹。
臟寫的問題太嚴重了，任何隔離級別都必須避免茵汰。其它無論是臟讀枢里，不可重復讀，還是幻讀蹂午，它們都屬于數據庫的讀一致性的問題栏豺，都是在一個事務里面前后兩次讀取出現(xiàn)了不一致的情況。
- 四種隔離級別
在SQL標準中設立了4種隔離級別豆胸，用來解決上面的讀一致性問題奥洼。不同的隔離級別可以解決不同的讀一致性問題。
READ UNCOMMITTED：未提交讀晚胡。READ COMMITTED：已提交讀灵奖。REPEATABLE READ：可重復讀嚼沿。SERIALIZABLE：串行化。
各個隔離級別下可能出現(xiàn)的讀一致性問題如下：
InnoDB支持四個隔離級別（和SQL標準定義的基本一致）瓷患。隔離級別越高骡尽，事務的并發(fā)度就越低。唯一的區(qū)別就在于擅编，InnoDB 在可重復讀（REPEATABLE READ）的級別就解決了幻讀的問題攀细。這也是InnoDB使用可重復讀 作為事務默認隔離級別的原因。
MVCC
MVCC(Multi Version Concurrency Control)沙咏，中文名是多版本并發(fā)控制辨图，簡單來說就是通過維護數據歷史版本班套，從而解決并發(fā)訪問情況下的讀一致性問題肢藐。
- 版本鏈
在InnoDB中，每行記錄實際上都包含了兩個隱藏字段：事務id(trx_id)和回滾指針(roll_pointer)吱韭。
-
trx_id：事務id吆豹。每次修改某行記錄時，都會把該事務的事務id賦值給trx_id隱藏列理盆。 -
roll_pointer：回滾指針痘煤。每次修改某行記錄時，都會把undo日志地址賦值給roll_pointer隱藏列猿规。
假設hero表中只有一行記錄衷快，當時插入的事務id為80。此時姨俩，該條記錄的示例圖如下：
假設之后兩個事務id分別為100蘸拔、200的事務對這條記錄進行UPDATE操作，操作流程如下：
由于每次變動都會先把undo日志記錄下來环葵，并用roll_pointer指向undo日志地址调窍。因此可以認為，對該條記錄的修改日志串聯(lián)起來就形成了一個版本鏈张遭，版本鏈的頭節(jié)點就是當前記錄最新的值邓萨。如下
- ReadView
如果數據庫隔離級別是未提交讀（READ UNCOMMITTED），那么讀取版本鏈中最新版本的記錄即可菊卷。如果是是串行化（SERIALIZABLE）缔恳，事務之間是加鎖執(zhí)行的，不存在讀不一致的問題洁闰。但是如果是已提交讀（READ COMMITTED）或者可重復讀（REPEATABLE READ）褐耳，就需要遍歷版本鏈中的每一條記錄，判斷該條記錄是否對當前事務可見渴庆，直到找到為止(遍歷完還沒找到就說明記錄不存在)铃芦。InnoDB通過ReadView實現(xiàn)了這個功能雅镊。ReadView中主要包含以下4個內容：
-
m_ids：表示在生成ReadView時當前系統(tǒng)中活躍的讀寫事務的事務id列表。 -
min_trx_id：表示在生成ReadView時當前系統(tǒng)中活躍的讀寫事務中最小的事務id刃滓，也就是m_ids中的最小值仁烹。 -
max_trx_id：表示生成ReadView時系統(tǒng)中應該分配給下一個事務的id值。 -
creator_trx_id：表示生成該ReadView事務的事務id咧虎。
有了ReadView之后卓缰，我們可以基于以下步驟判斷某個版本的記錄是否對當前事務可見。
- 如果被訪問版本的
trx_id屬性值與ReadView中的creator_trx_id值相同砰诵，意味著當前事務在訪問它自己修改過的記錄征唬，所以該版本可以被當前事務訪問。 - 如果被訪問版本的
trx_id屬性值小于ReadView中的min_trx_id值茁彭，表明生成該版本的事務在當前事務生成ReadView前已經提交总寒，所以該版本可以被當前事務訪問。 - 如果被訪問版本的
trx_id屬性值大于或等于ReadView中的max_trx_id值理肺，表明生成該版本的事務在當前事務生成ReadView后才開啟摄闸，所以該版本不可以被當前事務訪問。 - 如果被訪問版本的
trx_id屬性值在ReadView的min_trx_id和max_trx_id之間妹萨，那就需要判斷一下trx_id屬性值是不是在m_ids列表中年枕，如果在，說明創(chuàng)建ReadView時生成該版本的事務還是活躍的乎完，該版本不可以被訪問熏兄；如果不在，說明創(chuàng)建ReadView時生成該版本的事務已經被提交树姨，該版本可以被訪問摩桶。
在MySQL中，READ COMMITTED和REPEATABLE READ隔離級別的的一個非常大的區(qū)別就是它們生成ReadView的時機不同娃弓。READ COMMITTED在每次讀取數據前都會生成一個ReadView典格，這樣就能保證每次都能讀到其它事務已提交的數據。REPEATABLE READ 只在第一次讀取數據時生成一個ReadView台丛，這樣就能保證后續(xù)讀取的結果完全一致耍缴。
鎖
事務并發(fā)訪問同一數據資源的情況主要就分為讀-讀、寫-寫和讀-寫三種挽霉。
-
讀-讀即并發(fā)事務同時訪問同一行數據記錄防嗡。由于兩個事務都進行只讀操作，不會對記錄造成任何影響侠坎，因此并發(fā)讀完全允許蚁趁。 -
寫-寫即并發(fā)事務同時修改同一行數據記錄。這種情況下可能導致臟寫問題实胸，這是任何情況下都不允許發(fā)生的他嫡，因此只能通過加鎖實現(xiàn)番官，也就是當一個事務需要對某行記錄進行修改時，首先會先給這條記錄加鎖钢属，如果加鎖成功則繼續(xù)執(zhí)行徘熔，否則就排隊等待，事務執(zhí)行完成或回滾會自動釋放鎖淆党。 -
讀-寫即一個事務進行讀取操作酷师，另一個進行寫入操作。這種情況下可能會產生臟讀染乌、不可重復讀山孔、幻讀。最好的方案是讀操作利用多版本并發(fā)控制（MVCC）荷憋，寫操作進行加鎖台颠。
- 鎖的粒度
按鎖作用的數據范圍進行分類的話，鎖可以分為行級鎖和表級鎖台谊。
-
行級鎖：作用在數據行上蓉媳，鎖的粒度比較小譬挚。 -
表級鎖：作用在整張數據表上锅铅，鎖的粒度比較大。
- 鎖的分類
為了實現(xiàn)讀-讀之間不受影響减宣，并且寫-寫盐须、讀-寫之間能夠相互阻塞，Mysql使用了讀寫鎖的思路進行實現(xiàn)漆腌，具體來說就是分為了共享鎖和排它鎖：
-
共享鎖(Shared Locks)：簡稱S鎖贼邓，在事務要讀取一條記錄時，需要先獲取該記錄的S鎖闷尿。S鎖可以在同一時刻被多個事務同時持有塑径。我們可以用select ...... lock in share mode;的方式手工加上一把S鎖。 -
排他鎖(Exclusive Locks)：簡稱X鎖填具，在事務要改動一條記錄時统舀，需要先獲取該記錄的X鎖。X鎖在同一時刻最多只能被一個事務持有劳景。X鎖的加鎖方式有兩種誉简，第一種是自動加鎖，在對數據進行增刪改的時候盟广，都會默認加上一個X鎖闷串。還有一種是手工加鎖，我們用一個FOR UPDATE給一行數據加上一個X鎖筋量。
還需要注意的一點是烹吵，如果一個事務已經持有了某行記錄的S鎖碉熄，另一個事務是無法為這行記錄加上X鎖的，反之亦然肋拔。
除了共享鎖(Shared Locks)和排他鎖(Exclusive Locks)具被，Mysql還有意向鎖(Intention Locks)。意向鎖是由數據庫自己維護的只损，一般來說一姿，當我們給一行數據加上共享鎖之前，數據庫會自動在這張表上面加一個意向共享鎖(IS鎖)跃惫；當我們給一行數據加上排他鎖之前叮叹，數據庫會自動在這張表上面加一個意向排他鎖(IX鎖)。意向鎖可以認為是S鎖和X鎖在數據表上的標識爆存，通過意向鎖可以快速判斷表中是否有記錄被上鎖蛉顽，從而避免通過遍歷的方式來查看表中有沒有記錄被上鎖，提升加鎖效率先较。例如携冤，我們要加表級別的X鎖，這時候數據表里面如果存在行級別的X鎖或者S鎖的闲勺，加鎖就會失敗曾棕，此時直接根據意向鎖就能知道這張表是否有行級別的X鎖或者S鎖。
- InnoDB中的表級鎖
InnoDB中的表級鎖主要包括表級別的意向共享鎖(IS鎖)和意向排他鎖(IX鎖)以及自增鎖(AUTO-INC鎖)菜循。其中IS鎖和IX鎖在前面已經介紹過了翘地，這里不再贅述，我們接下來重點了解一下AUTO-INC鎖癌幕。
大家都知道衙耕，如果我們給某列字段加了AUTO_INCREMENT自增屬性，插入的時候不需要為該字段指定值勺远，系統(tǒng)會自動保證遞增橙喘。系統(tǒng)實現(xiàn)這種自動給AUTO_INCREMENT修飾的列遞增賦值的原理主要是兩個：
-
AUTO-INC鎖：在執(zhí)行插入語句的時先加上表級別的AUTO-INC鎖，插入執(zhí)行完成后立即釋放鎖胶逢。如果我們的插入語句在執(zhí)行前無法確定具體要插入多少條記錄厅瞎，比如INSERT ... SELECT這種插入語句，一般采用AUTO-INC鎖的方式宪塔。 -
輕量級鎖：在插入語句生成AUTO_INCREMENT值時先才獲取這個輕量級鎖磁奖，然后在AUTO_INCREMENT值生成之后就釋放輕量級鎖。如果我們的插入語句在執(zhí)行前就可以確定具體要插入多少條記錄某筐，那么一般采用輕量級鎖的方式對AUTO_INCREMENT修飾的列進行賦值比搭。這種方式可以避免鎖定表，可以提升插入性能。
mysql默認根據實際場景自動選擇加鎖方式身诺，當然也可以通過
innodb_autoinc_lock_mode強制指定只使用其中一種蜜托。
- InnoDB中的行級鎖
前面說過，通過MVCC可以解決臟讀霉赡、不可重復讀橄务、幻讀這些讀一致性問題，但實際上這只是解決了普通select語句的數據讀取問題穴亏。事務利用MVCC進行的讀取操作稱之為快照讀蜂挪，所有普通的SELECT語句在READ COMMITTED、REPEATABLE READ隔離級別下都算是快照讀嗓化。除了快照讀之外棠涮，還有一種是鎖定讀，即在讀取的時候給記錄加鎖刺覆，在鎖定讀的情況下依然要解決臟讀严肪、不可重復讀、幻讀的問題谦屑。由于都是在記錄上加鎖驳糯，這些鎖都屬于行級鎖。
InnoDB的行鎖氢橙，是通過鎖住索引來實現(xiàn)的酝枢，如果加鎖查詢的時候沒有使用過索引，會將整個聚簇索引都鎖住充蓝，相當于鎖表了隧枫。根據鎖定范圍的不同喉磁，行鎖可以使用記錄鎖(Record Locks)谓苟、間隙鎖(Gap Locks)和臨鍵鎖(Next-Key Locks)的方式實現(xiàn)。假設現(xiàn)在有一張表t协怒，主鍵是id涝焙。我們插入了4行數據，主鍵值分別是 1孕暇、4仑撞、7、10妖滔。接下來我們就以聚簇索引為例隧哮，具體介紹三種形式的行鎖。
- 記錄鎖(Record Locks) 所謂記錄座舍，就是指聚簇索引中真實存放的數據沮翔，比如上面的1、4曲秉、7采蚀、10都是記錄疲牵。
顯然，記錄鎖就是直接鎖定某行記錄榆鼠。當我們使用唯一性的索引(包括唯一索引和聚簇索引)進行等值查詢且精準匹配到一條記錄時纲爸，此時就會直接將這條記錄鎖定。例如select * from t where id =4 for update;就會將id=4的記錄鎖定妆够。
- 間隙鎖(Gap Locks) 間隙指的是兩個記錄之間邏輯上尚未填入數據的部分识啦，比如上述的(1,4)、(4,7)等神妹。
同理袁滥，間隙鎖就是鎖定某些間隙區(qū)間的。當我們使用用等值查詢或者范圍查詢灾螃，并且沒有命中任何一個record题翻，此時就會將對應的間隙區(qū)間鎖定。例如select * from t where id =3 for update;或者select * from t where id > 1 and id < 4 for update;就會將(1,4)區(qū)間鎖定腰鬼。
- 臨鍵鎖(Next-Key Locks) 臨鍵指的是間隙加上它右邊的記錄組成的左開右閉區(qū)間嵌赠。比如上述的(1,4]、(4,7]等熄赡。
臨鍵鎖就是記錄鎖(Record Locks)和間隙鎖(Gap Locks)的結合姜挺，即除了鎖住記錄本身，還要再鎖住索引之間的間隙彼硫。當我們使用范圍查詢炊豪，并且命中了部分record記錄，此時鎖住的就是臨鍵區(qū)間拧篮。注意词渤，臨鍵鎖鎖住的區(qū)間會包含最后一個record的右邊的臨鍵區(qū)間。例如select * from t where id > 5 and id <= 7 for update;會鎖住(4,7]串绩、(7,+∞)缺虐。mysql默認行鎖類型就是臨鍵鎖(Next-Key Locks)。當使用唯一性索引礁凡，等值查詢匹配到一條記錄的時候高氮，臨鍵鎖(Next-Key Locks)會退化成記錄鎖；沒有匹配到任何記錄的時候顷牌，退化成間隙鎖剪芍。
間隙鎖(Gap Locks)和臨鍵鎖(Next-Key Locks)都是用來解決幻讀問題的，在已提交讀（READ COMMITTED）隔離級別下窟蓝，間隙鎖(Gap Locks)和臨鍵鎖(Next-Key Locks)都會失效罪裹！
寫在最后
歡迎大家關注我的公眾號【風平浪靜如碼】，海量Java相關文章，學習資料都會在里面更新坊谁，整理的資料也會放在里面费彼。
覺得寫的還不錯的就點個贊，加個關注唄口芍！點關注箍铲，不迷路，持續(xù)更新ｗ尥帧５吆铩！
