MySQL 核心模塊揭秘 | 鎖在內存里長什么樣？
1. 共用的結構
InnoDB 的表鎖結構和行鎖結構，有一些共同屬性，也有一些不同屬性。
因為有共同屬性，表鎖結構和行鎖結構都使用結構體 lock_t 來表示鎖結構。
在 lock_t 之下，又定義了 lock_table_t、lock_rec_t 分別包含表鎖結構和行鎖結構的不同屬性。
為了更直觀的理解表鎖結構和行鎖結構，我們去掉 lock_t 的一些非核心信息之后，整理如下：
// storage/innobase/include/lock0priv.h
struct lock_t {
trx_t *trx;
UT_LIST_NODE_T(lock_t) trx_locks;
dict_index_t *index;
lock_t *hash;
union {
lock_table_t tab_lock;
lock_rec_t rec_lock;
};
uint32_t type_mode;
};雖然表鎖結構和行鎖結構都定義了自己的結構體，用于表示各自不同的屬性，但是 lock_t 中 index、hash 這兩個只用于行鎖結構的屬性，并沒有放入 lock_rec_t。
我們就不去追溯為什么這兩個屬性會放在 lock_t 中，而沒有放入 lock_rec_t 了。
2. type_mode
從屬性名上看，表鎖結構和行鎖結構的 type_mode 屬性存放的是鎖類型和鎖模式。
實際上，這個屬性比較復雜，它占用 4 字節，共 32 位，分為四個部分。
圖片
第一部分，1 ~ 4 位，這 4 位是個整體，共同表示一個整數值，就是鎖模式。
- 0（LOCK_IS），表級別的意向共享鎖。
- 1（LOCK_IX），表級別的意向排他鎖。
- 2（LOCK_S），表級別或行級別的共享鎖。
- 3（LOCK_X），表級別或行級別的排他鎖。
- 4（LOCK_AUTO_INC），表級別的 Auto-Inc 鎖。
鎖模式部分的 4 字節，作為一個整體使用，而沒有按位使用，這是有原因的。
按整體使用，4 字節的無符號整數最大值為 15，最多可以表示 15 種鎖模式。
按位使用，每位只能表示一種鎖模式，4 位只能表示 4 種鎖模式。
第二部分，5 ~ 8 位，按位使用，存放的是鎖類型。
- 第 5 位標識是否為表鎖（LOCK_TABLE）。
- 第 6 位標識是否為行鎖（LOCK_REC）。
- 第 7 ~ 8 位，暫未使用。
第三部分，第 9 位，按位使用，存放的是鎖等待狀態（LOCK_WAIT），置為 0 表示已經獲得鎖，置為 1 表示處于鎖等待狀態。
第四部分，10 ~ 32 位，按位使用，存放的是鎖的精確模式，這部分只有行鎖和謂詞鎖會用到，表鎖不會用到。
- 第 10 位用于標識間隙鎖（LOCK_GAP）。
- 第 11 位用于標識普通記錄鎖（LOCK_REC_NOT_GAP）。
- 第 12 位用于標識插入意向鎖（LOCK_INSERT_INTENTION）。
- 第 13 位，暫未使用。
- 第 14 ~ 15 位分別用于標識 LOCK_PREDICATE、LOCK_PRDT_PAGE，都屬于謂詞鎖。
- 第 16 ~ 32 位，暫未使用。
看到這里，大家有沒有覺得奇怪，怎么沒有用于標識 Next-Key 的位置？
鎖模式為行鎖（LOCK_REC）時，如果 10 ~ 32 位中所有位都被設置為 0，就表示加的行鎖是 Next-Key 鎖。
3. 表鎖結構
lock_t 中，表鎖結構只使用 trx、trx_locks、type_mode 三個屬性，加上 lock_table_t 的 table、locks 屬性，就是表鎖結構的全部屬性了。
圖片
MySQL 執行 DDL、DML 語句時，InnoDB 都會有對應的事務（用戶手動啟動或者 InnoDB 自動啟動）來執行這些語句對應的操作。
加鎖操作自然也是在事務中進行的，trx 屬性就是加這個表鎖的事務對象。
事務執行一條或多條 DML 語句，可能涉及多個表，也就有可能加多個表鎖。事務除了加表鎖，還有可能加行鎖，同一個事務加的一個或多個表鎖和一個或多個行鎖的鎖結構通過 trx_locks 屬性形成一個表鎖結構和行鎖結構混合的鏈表。
表鎖是加在表上的，自然就需要知道表鎖結構屬于哪個表了，table 屬性就是這個表鎖結構所屬的表對象。
同一時刻，可能有多個事務已經或者想要對同一個表加鎖。對于兼容的表鎖，多個事務可以同時加鎖，對于不兼容的表鎖，后加鎖的事務就會處于等待狀態。
事務想要對某個表加鎖，InnoDB 怎么判斷事務可以立即獲得鎖，還是要進入等待狀態？
這就是 locks 屬性的用武之地了。
多個事務對同一個表加了表鎖，這些表鎖的鎖結構會通過 locks 屬性形成一個鏈表。
事務想要對某個表加表鎖，InnoDB 就會遍歷這個鏈表。
如果鏈表中還沒有表鎖結構，或者所有鎖結構對應的表鎖都和事務當前要加的表鎖兼容，事務就可以立即獲得鎖，否則就需要進入等待狀態。
type_mode 屬性的第 5 位用于標識鎖結構是否為表鎖（LOCK_TABLE）。
對于表鎖，鎖結構中 type_mode 屬性的第 5 位會被設置為 1，第 1 ~ 4 位會寫入鎖模式對應的整數值。
如果事務不能立即獲得表鎖，type_mode 屬性的第 9 位會被設置為 1，表示處于鎖等待狀態。
4. 行鎖結構
lock_t 中，行鎖結構使用 trx、trx_locks、index、hash、type_mode 五個屬性，加上 lock_rec_t 的 page_id、n_bits 兩個屬性，外加行鎖結構最后外掛了一塊沒有屬性名的內存區域（我們暫且命名為 bitmap），就是行鎖的整體結構了。
圖片
4.1 有名有姓的那些屬性
和表鎖結構一樣，行鎖結構里也有 trx 和 trx_locks 兩個屬性。
trx 屬性是加這個行鎖的事務對象。同一個事務加的一個或多個表鎖和一個或多個行鎖的鎖結構，通過 trx_locks 屬性形成一個表鎖結構和行鎖結構混合的鏈表。
主表的記錄存儲在主鍵索引中，二級索引（包括唯一索引、非唯一索引）的記錄存儲在二級索引中，行鎖都是對主鍵索引或二級索引的記錄加鎖。index 屬性就是這個行鎖結構所屬的索引對象。
InnoDB 可能同時有很多個事務在運行，這些事務加的行鎖，可能會產生多個行鎖結構。
每個行鎖結構都會根據 page_id 屬性中保存的表空間 ID、數據頁號計算得到一個哈希值。哈希值相同的多個行鎖結構通過 hash 屬性形成一個行鎖結構鏈表。
n_bits 屬性的值是個無符號整數，表示這個鎖結構能保存多少條記錄的行鎖狀態，也就是最多有多少記錄能共用這個行鎖結構。
對于行鎖，鎖結構中 type_mode 屬性的第 6 位會被設置為 1，第 1 ~ 4 位會被寫入鎖模式對應的整數值。
行鎖的不同精確模式，type_mode 屬性第四部分（10 ~ 32 位）各位的賦值情況如下：
- 普通記錄鎖，type_mode 屬性的第 10 位會被設置為 1。
- 間隙鎖，type_mode 屬性的第 11 位會被設置為 1。
- 插入意向鎖，type_mode 屬性的第 12 位會被設置為 1。
- Next-Key 鎖，type_mode 屬性的第 10 ~ 32 位都設置為 0。
如果事務不能立即獲得行鎖，type_mode 屬性的第 9 位會被設置為 1，表示處于鎖等待狀態。
4.2 隱姓埋名的內存區域
前面介紹的那些，都是 InnoDB 給取了名字的行鎖結構屬性。
還有一塊沒有名字的內存區域沒有介紹。在前面的行鎖結構圖中，我們給這塊內存區域取了個名字，為 bitmap。
bitmap 這塊內存區域是干嘛用的呢？
待我們細細說來。
我們先忽略 bitmap 內存區域的存在，假設一個事務對一條記錄加行鎖，會產生一個行鎖結構，對多條記錄加行鎖，就會產生多個行鎖結構。
又假設事務對多條記錄加的都是共享 Next-Key 鎖，并且已經獲得了鎖，巧合的是這些記錄又位于同一個數據頁，那么，這些鎖結構除了加鎖記錄不一樣，其它屬性的值都相同。
如果真這么設計行鎖結構，是不是太浪費內存空間了？
當然是了。雖然現在內存越來越便宜，但是畢竟還要花錢，也不能那么鋪張浪費。
本著勤儉節約的原則，InnoDB 把加鎖記錄不同、其它屬性值都相同的多個行鎖結構合并成一個，另外開辟一塊內存區域用于標識加鎖記錄，于是就有了我們命名為 bitmap 的內存區域。
bitmap 內存區域按位使用，每一位都用于標識事務是否對某條記錄加了行鎖。如果某一位被設置為 1，就表示事務對該位對應的記錄加了行鎖。
圖片
上圖是事務對象初始化時，預先創建的一個行鎖結構的 bitmap 內存區域示意圖，大小為 256 字節，可以用于標識這個事務對 2048 條記錄加行鎖的情況。
示意圖中，第 3 位和第 5 位被設置為 1，說明事務對數據頁中序號為 0 和 4 的記錄加了行鎖。
沒有規矩不成方圓，InnoDB 不會胡亂的把多個行鎖結構合并成一個。
事務對多條記錄加行鎖，想要共用一個行鎖結構，需要同時滿足以下個條件：
- 同一個事務對多條記錄加行鎖。
- 這些記錄位于同一個數據頁中（也就是同一個表同一個索引的同一個數據頁）。
- 這些行鎖的鎖模式相同，必須都是共享鎖，或者都是排他鎖。
- 這些行鎖的精確模式相同，必須都是普通記錄鎖，或者都是間隙鎖，或者都是 Next-Key 鎖。
- 這些行鎖都處于獲得鎖的狀態，不能處于鎖等待狀態。
4.3 共用行鎖結構的兩個問題
問題一：多個處于等待狀態的行鎖能共用一個鎖結構嗎？
理論上是可以的，但實際上不會出現這種情況。
因為共用一個行鎖結構需要滿足的條件之一，是一個事務對多條記錄加行鎖。
然而，一個事務對某條記錄加行鎖處于等待狀態，在獲得鎖或者鎖超時之前（不考慮異常情況），這個事務不會繼續往下執行。
這樣一來，一個事務在某一時刻，最多只有一個行鎖結構（對應一條記錄）處于等待狀態，也就不存在多個處于等待狀態的行鎖共用一個行鎖結構的情況了。
獲得鎖或者鎖等待超時之后，行鎖結構中 type_mode 的第 9 位就會被設置為 0，表示這個行鎖處于非等待狀態，后續在滿足共用條件的情況下，這個鎖結構才可以被共用。
問題二：多個插入意向鎖能共用一個鎖結構嗎？
同樣，理論上是可以的，但實際上不會出現這種情況。
首先，插入意向鎖的加鎖場景，是事務 T 想要在某條記錄前面的間隙插入一條記錄，而這個間隙被其它事務加了間隙鎖或者 Next-Key 鎖，導致事務 T 必須在這個間隙上加插入意向鎖，并等待其它事務釋放間隙鎖或者 Next-Key 鎖。
前面已經介紹過，處于等待狀態的行鎖結構，是不能共用的。
然后，事務 T 獲得鎖之后，它的精確模式為 LOCK_GAP + LOCK_INSERT_INTENTION，其它間隙鎖也不能共用這個鎖結構，因為間隙鎖的精確模式為 LOCK_GAP。
雖然插入意向鎖的鎖結構不能共用，會浪費一些內存，但好在加插入意向鎖的情況也不會非常多，浪費的內存也就不會太多。
5. 總結
InnoDB 的表鎖結構和行鎖結構，有一部分屬性是相同的，也有一部分屬性是專用的，所以，代碼里定義了三個結構體來描述表鎖結構和行鎖結構。
一個事務對每個表加表鎖，都會產生一個表鎖結構。
一個事務對多條記錄加行鎖，滿足條件時，多條記錄的行鎖可以共用一個行鎖結構，以節省內存。
處于等待狀態的行鎖結構，不能共用。獲得行鎖或者鎖等待超時之后，這個鎖結構會變為非等待狀態，之后滿足條件時，這個鎖結構可以被共用。
插入意向鎖的鎖結構不能共用。
