前言
衆所周知，事務和鎖是mysql中非常重要功能，同時也是面試的重點和難點。本文會詳細介紹事務和鎖的相關概念及其實作原理，相信大家看完之後，一定會對事務和鎖有更加深入的了解。
什麼是事務
在維基百科中，對事務的定義是：事務是資料庫管理系統(DBMS)執行過程中的一個邏輯機關，由一個有限的資料庫操作序列構成。
事務的四大特性
事務包含四大特性，即原子性（Atomicity）、一緻性（Consistency）、隔離性（Isolation）和持久性（Durability）(ACID)。
1.原子性（Atomicity）
原子性是指對資料庫的一系列操作，要麼全部成功，要麼全部失敗，不可能出現部分成功的情況。以轉賬場景為例，一個賬戶的餘額減少，另一個賬戶的餘額增加，這兩個操作一定是同時成功或者同時失敗的。
2.一緻性（Consistency）
一緻性是指資料庫的完整性限制沒有被破壞，在事務執行前後都是合法的資料狀态。這裡的一緻可以表示資料庫自身的限制沒有被破壞，比如某些字段的唯一性限制、字段長度限制等等；還可以表示各種實際場景下的業務限制，比如上面轉賬操作，一個賬戶減少的金額和另一個賬戶增加的金額一定是一樣的。
3.隔離性（Isolation）
隔離性指的是多個事務彼此之間是完全隔離、互不幹擾的。隔離性的最終目的也是為了保證一緻性。
4.持久性（Durability）
持久性是指隻要事務送出成功，那麼對資料庫做的修改就被永久儲存下來了，不可能因為任何原因再回到原來的狀态。
事務的狀态
根據事務所處的不同階段，事務大緻可以分為以下5個狀态：
1.活動的（active）
當事務對應的資料庫操作正在執行過程中，則該事務處于活動狀态。
2.部分送出的（partially committed）
當事務中的最後一個操作執行完成，但還未将變更重新整理到磁盤時，則該事務處于部分送出狀态。
3.失敗的（failed）
當事務處于活動或者部分送出狀态時，由于某些錯誤導緻事務無法繼續執行，則事務處于失敗狀态。
4.中止的（aborted）
當事務處于失敗狀态，且復原操作執行完畢，資料恢複到事務執行之前的狀态時，則該事務處于中止狀态。
5.送出的（committed）
當事務處于部分送出狀态，并且将修改過的資料都同步到磁盤之後，此時該事務處于送出狀态。
事務隔離級别
前面提到過，事務必須具有隔離性。實作隔離性最簡單的方式就是不允許事務并發，每個事務都排隊執行，但是這種方式性能實在太差了。為了兼顧事務的隔離性和性能，事務支援不同的隔離級别。
為了友善表述後續的内容，我們先建一張示例表hero。
CREATE TABLE hero (
number INT,
name VARCHAR(100),
country varchar(100),
PRIMARY KEY (number)
) Engine=InnoDB CHARSET=utf8;
事務并發執行遇到的問題
在事務并發執行時，如果不進行任何控制，可能會出現以下4類問題：
1.髒寫（Dirty Write）
髒寫是指一個事務修改了其它事務未送出的資料。
如上圖，Session A和Session B各開啟了一個事務，Session B中的事務先将number列為1的記錄的name列更新為’關羽’，然後Session A中的事務接着又把這條number列為1的記錄的name列更新為張飛。如果之後Session B中的事務進行了復原，那麼Session A中的更新也将不複存在，這種現象就稱之為髒寫。
2.髒讀（Dirty Read）
髒讀是指一個事務讀到了其它事務未送出的資料。
如上圖，Session A和Session B各開啟了一個事務，Session B中的事務先将number列為1的記錄的name列更新為’關羽’，然後Session A中的事務再去查詢這條number為1的記錄，如果讀到列name的值為’關羽’，而Session B中的事務稍後進行了復原，那麼Session A中的事務相當于讀到了一個不存在的資料，這種現象就稱之為髒讀。
3.不可重複讀（Non-Repeatable Read）
不可重複讀指的是在一個事務執行過程中，讀取到其它事務已送出的資料，導緻兩次讀取的結果不一緻。
如上圖，我們在Session B中送出了幾個隐式事務(mysql會自動為增删改語句加事務)，這些事務都修改了number列為1的記錄的列name的值，每次事務送出之後，如果Session A中的事務都可以檢視到最新的值，這種現象也被稱之為不可重複讀。
4.幻讀（Phantom）
幻讀是指的是在一個事務執行過程中，讀取到了其他事務新插入資料，導緻兩次讀取的結果不一緻。
如上圖，Session A中的事務先根據條件number > 0這個條件查詢表hero，得到了name列值為’劉備’的記錄；之後Session B中送出了一個隐式事務，該事務向表hero中插入了一條新記錄；之後Session A中的事務再根據相同的條件number > 0查詢表hero，得到的結果集中包含Session B中的事務新插入的那條記錄，這種現象也被稱之為幻讀。
不可重複讀和幻讀的差別在于不可重複讀是讀到的是其他事務修改或者删除的資料，而幻讀讀到的是其它事務新插入的資料。
髒寫的問題太嚴重了，任何隔離級别都必須避免。其它無論是髒讀，不可重複讀，還是幻讀，它們都屬于資料庫的讀一緻性的問題，都是在一個事務裡面前後兩次讀取出現了不一緻的情況。
四種隔離級别
在SQL标準中設立了4種隔離級别，用來解決上面的讀一緻性問題。不同的隔離級别可以解決不同的讀一緻性問題。
1.READ UNCOMMITTED
未送出讀。
2.READ COMMITTED
已送出讀。
3.REPEATABLE READ
可重複讀。
4.SERIALIZABLE
串行化。
各個隔離級别下可能出現的讀一緻性問題如下：
InnoDB支援四個隔離級别（和SQL标準定義的基本一緻）。隔離級别越高，事務的并發度就越低。唯一的差別就在于，InnoDB 在可重複讀（REPEATABLE READ）的級别就解決了幻讀的問題。這也是InnoDB使用可重複讀 作為事務預設隔離級别的原因。
MVCC
MVCC(Multi Version Concurrency Control)，中文名是多版本并發控制，簡單來說就是通過維護資料曆史版本，進而解決并發通路情況下的讀一緻性問題。
版本鍊
在InnoDB中，每行記錄實際上都包含了兩個隐藏字段：事務id(trx_id)和復原指針(roll_pointer)。
1.trx_id
事務id。每次修改某行記錄時，都會把該事務的事務id指派給trx_id隐藏列。
2.roll_pointer
復原指針。每次修改某行記錄時，都會把undo日志位址指派給roll_pointer隐藏列。
假設hero表中隻有一行記錄，當時插入的事務id為80。此時，該條記錄的示例圖如下：
假設之後兩個事務id分别為100、200的事務對這條記錄進行UPDATE操作，操作流程如下：
由于每次變動都會先把undo日志記錄下來，并用roll_pointer指向undo日志位址。是以可以認為，對該條記錄的修改日志串聯起來就形成了一個版本鍊，版本鍊的頭節點就是目前記錄最新的值。如下：
ReadView
如果資料庫隔離級别是未送出讀（READ UNCOMMITTED），那麼讀取版本鍊中最新版本的記錄即可。如果是是串行化（SERIALIZABLE），事務之間是加鎖執行的，不存在讀不一緻的問題。但是如果是已送出讀（READ COMMITTED）或者可重複讀（REPEATABLE READ），就需要周遊版本鍊中的每一條記錄，判斷該條記錄是否對目前事務可見，直到找到為止(周遊完還沒找到就說明記錄不存在)。InnoDB通過ReadView實作了這個功能。ReadView中主要包含以下4個内容：
1.m_ids
表示在生成ReadView時目前系統中活躍的讀寫事務的事務id清單。
2.min_trx_id
表示在生成ReadView時目前系統中活躍的讀寫事務中最小的事務id，也就是m_ids中的最小值。
3.max_trx_id
表示生成ReadView時系統中應該配置設定給下一個事務的id值。
4.creator_trx_id
表示生成該ReadView事務的事務id。
有了ReadView之後，我們可以基于以下步驟判斷某個版本的記錄是否對目前事務可見。
1.如果被通路版本的trx_id屬性值與ReadView中的creator_trx_id值相同，意味着目前事務在通路它自己修改過的記錄，是以該版本可以被目前事務通路。
2.如果被通路版本的trx_id屬性值小于ReadView中的min_trx_id值，表明生成該版本的事務在目前事務生成ReadView前已經送出，是以該版本可以被目前事務通路。
3.如果被通路版本的trx_id屬性值大于或等于ReadView中的max_trx_id值，表明生成該版本的事務在目前事務生成ReadView後才開啟，是以該版本不可以被目前事務通路。
4.如果被通路版本的trx_id屬性值在ReadView的min_trx_id和max_trx_id之間，那就需要判斷一下trx_id屬性值是不是在m_ids清單中，如果在，說明建立ReadView時生成該版本的事務還是活躍的，該版本不可以被通路；如果不在，說明建立ReadView時生成該版本的事務已經被送出，該版本可以被通路。
在MySQL中，READ COMMITTED和REPEATABLE READ隔離級别的的一個非常大的差別就是它們生成ReadView的時機不同。READ COMMITTED在每次讀取資料前都會生成一個ReadView，這樣就能保證每次都能讀到其它事務已送出的資料。REPEATABLE READ 隻在第一次讀取資料時生成一個ReadView，這樣就能保證後續讀取的結果完全一緻。
鎖
事務并發通路同一資料資源的情況主要就分為讀-讀、寫-寫和讀-寫三種。
1.讀-讀
即并發事務同時通路同一行資料記錄。由于兩個事務都進行隻讀操作，不會對記錄造成任何影響，是以并發讀完全允許。
2.寫-寫
即并發事務同時修改同一行資料記錄。這種情況下可能導緻髒寫問題，這是任何情況下都不允許發生的，是以隻能通過加鎖實作，也就是當一個事務需要對某行記錄進行修改時，首先會先給這條記錄加鎖，如果加鎖成功則繼續執行，否則就排隊等待，事務執行完成或復原會自動釋放鎖。
3.讀-寫
即一個事務進行讀取操作，另一個進行寫入操作。這種情況下可能會産生髒讀、不可重複讀、幻讀。最好的方案是讀操作利用多版本并發控制（MVCC），寫操作進行加鎖。
鎖的粒度
按鎖作用的資料範圍進行分類的話，鎖可以分為行級鎖和表級鎖。
1.行級鎖
作用在資料行上，鎖的粒度比較小。
2.表級鎖
作用在整張資料表上，鎖的粒度比較大。
鎖的分類
為了實作讀-讀之間不受影響，并且寫-寫、讀-寫之間能夠互相阻塞，Mysql使用了讀寫鎖的思路進行實作，具體來說就是分為了共享鎖和排它鎖：
1.共享鎖(Shared Locks)
簡稱S鎖，在事務要讀取一條記錄時，需要先擷取該記錄的S鎖。S鎖可以在同一時刻被多個事務同時持有。我們可以用select … lock in share mode;的方式手工加上一把S鎖。
2.排他鎖(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自增屬性，插入的時候不需要為該字段指定值，系統會自動保證遞增。系統實作這種自動給AUTO_INCREMENT修飾的列遞增指派的原理主要是兩個：
1.AUTO-INC鎖
在執行插入語句的時先加上表級别的AUTO-INC鎖，插入執行完成後立即釋放鎖。如果我們的插入語句在執行前無法确定具體要插入多少條記錄，比如INSERT … SELECT這種插入語句，一般采用AUTO-INC鎖的方式。
2.輕量級鎖
在插入語句生成AUTO_INCREMENT值時先才擷取這個輕量級鎖，然後在AUTO_INCREMENT值生成之後就釋放輕量級鎖。如果我們的插入語句在執行前就可以确定具體要插入多少條記錄，那麼一般采用輕量級鎖的方式對AUTO_INCREMENT修飾的列進行指派。這種方式可以避免鎖定表，可以提升插入性能。
mysql預設根據實際場景自動選擇加鎖方式，當然也可以通過innodb_autoinc_lock_mode強制指定隻使用其中一種。
InnoDB中的行級鎖
前面說過，通過MVCC可以解決髒讀、不可重複讀、幻讀這些讀一緻性問題，但實際上這隻是解決了普通select語句的資料讀取問題。事務利用MVCC進行的讀取操作稱之為快照讀，所有普通的SELECT語句在READ COMMITTED、REPEATABLE READ隔離級别下都算是快照讀。除了快照讀之外，還有一種是鎖定讀，即在讀取的時候給記錄加鎖，在鎖定讀的情況下依然要解決髒讀、不可重複讀、幻讀的問題。由于都是在記錄上加鎖，這些鎖都屬于行級鎖。
InnoDB的行鎖，是通過鎖住索引來實作的，如果加鎖查詢的時候沒有使用過索引，會将整個聚簇索引都鎖住，相當于鎖表了。根據鎖定範圍的不同，行鎖可以使用記錄鎖(Record Locks)、間隙鎖(Gap Locks)和臨鍵鎖(Next-Key Locks)的方式實作。假設現在有一張表t，主鍵是id。我們插入了4行資料，主鍵值分别是 1、4、7、10。接下來我們就以聚簇索引為例，具體介紹三種形式的行鎖。
1.記錄鎖(Record Locks)
所謂記錄，就是指聚簇索引中真實存放的資料，比如上面的1、4、7、10都是記錄。
顯然，記錄鎖就是直接鎖定某行記錄。當我們使用唯一性的索引(包括唯一索引和聚簇索引)進行等值查詢且精準比對到一條記錄時，此時就會直接将這條記錄鎖定。例如select * from t where id =4 for update;就會将id=4的記錄鎖定。
2.間隙鎖(Gap Locks)
間隙指的是兩個記錄之間邏輯上尚未填入資料的部分，比如上述的(1,4)、(4,7)等。
同理，間隙鎖就是鎖定某些間隙區間的。當我們使用用等值查詢或者範圍查詢，并且沒有命中任何一個record，此時就會将對應的間隙區間鎖定。例如select * from t where id =3 for update;或者select * from t where id > 1 and id < 4 for update;就會将(1,4)區間鎖定。
3.臨鍵鎖(Next-Key Locks)
臨鍵指的是間隙加上它右邊的記錄組成的左開右閉區間。比如上述的(1,4]、(4,7]等。
臨鍵鎖就是記錄鎖(Record Locks)和間隙鎖(Gap Locks)的結合，即除了鎖住記錄本身，還要再鎖住索引之間的間隙。
當我們使用範圍查詢，并且命中了部分record記錄，此時鎖住的就是臨鍵區間。注意，臨鍵鎖鎖住的區間會包含最後一個record的右邊的臨鍵區間。
例如select * from t where id > 5 and id <= 7 for update;會鎖住(4,7]、(7,+∞)。mysql預設行鎖類型就是臨鍵鎖(Next-Key Locks)。
當使用唯一性索引，等值查詢比對到一條記錄的時候，臨鍵鎖(Next-Key Locks)會退化成記錄鎖；沒有比對到任何記錄的時候，退化成間隙鎖。
最後
我這邊整理了一份：
版權聲明：本文為CSDN部落客「m0_48795607」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。
原文連結：https://blog.csdn.net/m0_48795607/article/details/112881436