InnoDB 中管理表鎖和行鎖的鎖模塊，也就是傳說中的鎖子系統，在內存里是什么樣的？

作者：操盛春，愛可生技術專家，公眾號『一樹一溪』作者，專注于研究 MySQL 和 OceanBase 源碼。

愛可生開源社區出品，原創內容未經授權不得隨意使用，轉載請聯系小編并注明來源。

本文基于 MySQL 8.0.32 源碼，存儲引擎為 InnoDB。

1. 引言

前面三篇文章，我們分別介紹了 InnoDB 表鎖、行鎖，以及它們的鎖結構。

表鎖結構和行鎖結構是鎖模塊的基礎組成部分，它們就像一塊磚，哪里需要哪里搬。

然而，要蓋房子，光有磚不行，還得有鋼筋、水泥等材料，這些材料就由鎖模塊結構提供。

鎖模塊結構只有一個對象（lock_sys），在 InnoDB 中是全局唯一的。

2. 鎖模塊結構

鎖模塊結構類型為 lock_sys_t，去掉注釋以及兩個無關緊要的屬性之后，簡化如下：

struct lock_sys_t {locksys::Latches latches;hash_table_t *rec_hash;hash_table_t *prdt_hash;hash_table_t *prdt_page_hash;Lock_mutex wait_mutex;srv_slot_t *waiting_threads;srv_slot_t *last_slot;bool rollback_complete;std::chrono::steady_clock::duration n_lock_max_wait_time;os_event_t timeout_event;
}

單從屬性數量上看，鎖模塊結構并不復雜，甚至可以說比較簡單。

其實，鎖模塊的復雜性，不在于表鎖結構、行鎖結構，也不在于鎖模塊結構，而是在于各個事務、各種加鎖場景相互交錯導致的錯綜復雜的加鎖結果。

例如，一個事務等待獲得另一個事務持有的鎖，雖然會出現或長或短的等待鏈，但也不算太壞的情況。更壞的情況是出現了環形的等待鏈，也就是出現了死鎖。

如果出現死鎖，我們又需要被動復現死鎖，以解釋形成死鎖的原因，那簡直頭大了。

為了不滑入復雜的深淵，我們就此打住，先來介紹鎖模塊結構的屬性。

鎖模塊結構中有三個類型為 hash_table_t 的屬性，分別是 rec_hash、prdt_hash、prdt_page_hash。

其中，prdt_hash、prdt_page_hash 由謂詞鎖使用。我們并不打算介紹謂詞鎖，忽略這兩個屬性，也就順理成章了。

n_lock_max_wait_time 屬性的值是 MySQL 本次啟動以來，行鎖的最長等待時間。通過以下命令可以查詢到這個屬性的值：

show status like 'innodb_row_lock_time_max';+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| Innodb_row_lock_time_max | 50157 |
+--------------------------+-------+

rollback_complete 屬性，用于 MySQL 啟動過程中，標識從 undo 日志中恢復出來的、需要回滾的事務是否已全部回滾完成。

如果 rollback_complete = false，說明從 undo 日志中恢復出來的、需要回滾的事務還沒有全部回滾完成，InnoDB 會遍歷讀寫事務鏈表（trx_sys->rw_trx_list），釋放這些事務加的表鎖和行鎖。

這些事務全部回滾完成之后，rollback_complete 會被修改為 true。

前面介紹了鎖模塊結構中兩個比較簡單的屬性，剩下的其它屬性，我們分為幾個小節一一介紹。

2.1 誰來管理行鎖結構？

上一篇文章，我們介紹過，事務對多條記錄加行鎖，滿足條件時，可以共用一個行鎖結構。

雖然共用能減少行鎖結構的數量，但是，同一時刻，InnoDB 中可能還是有很多行鎖結構。

這么多行鎖結構，要怎么組織，用到時才能方便、快速的找到呢？

這就需要用到鎖模塊結構的 rec_hash 屬性了。

rec_hash 屬性是個哈希表，它的類型為 hash_table_t，創建鎖模塊對象（lock_sys）之后分配內存：

void lock_sys_create(ulint n_cells)
{...// 創建鎖模塊對象，分配內存lock_sys = static_cast<lock_sys_t *>(ut::zalloc_withkey(...));...// 創建哈希表（rec_hash），分配內存lock_sys->rec_hash =ut::new_<hash_table_t>(n_cells);...
}

lock_sys_create() 由 srv_start() 調用：

dberr_t srv_start(bool create_new_db) {...lock_sys_create(srv_lock_table_size);...
}

變量 srv_lock_table_size 在 innodb_init_params() 中賦值，它的值會傳遞給 lock_sys_create() 的參數 n_cells。

static int innodb_init_params() {...srv_lock_table_size = 5 * (srv_buf_pool_size / UNIV_PAGE_SIZE);...
}

srv_buf_pool_size 是 buffer pool 的大小，UNIV_PAGE_SIZE 是一個數據頁的大小，它們的單位都是字節。

以 buffer pool 大小為 128M、數據頁大小為 16K 為例，變量 srv_lock_table_size 的值計算如下：

// 128M = 134217728 字節
// 16K  = 16384 字節
srv_lock_table_size = 5 * (134217728 / 16384) = 40960

變量 srv_lock_table_size 的值（40960）最終會傳遞給 lock_sys_create() 的參數 n_cells。用 40960 替換 n_cells 之后如下：

void lock_sys_create(ulint n_cells)
{...lock_sys->rec_hash = ut::new_<hash_table_t>(40960);...
}

以上代碼說明 buffer pool 大小為 128M，數據頁大小為 16K 時，鎖模塊結構的 rec_hash 屬性有 40960 個格子。

每個格子都有編號，從 0 開始，一直到 40959。

這些格子并不是用來存儲行鎖結構，而是用來管理行鎖結構，它們的作用相當于線頭，找到了線頭就能牽出一根線。

創建行鎖結構之后，會先根據行鎖結構中那些記錄所屬數據頁的頁號和表空間 ID，計算得到哈希值，再根據哈希值計算得到格子的編號。

多個行鎖結構可能計算得到相同的哈希值，從而得到相同的編號，對應到同一個格子，這些行鎖結構通過各自的 hash 屬性形成一個行鎖結構鏈表。如果我們把這個鏈表看成一根線，這個格子就是這根線的線頭。

計算出格子編號之后，行鎖結構會插入到格子對應的行鎖結構鏈表的最前面。

想要找到某個行鎖結構，也需要根據同樣的規則，計算得到格子編號，再根據編號找到格子，最后遍歷這個格子對應的行鎖結構鏈表，以找到目標行鎖結構。

2.2 誰來保護表鎖和行鎖結構？

前面我們介紹了 rec_hash 是個哈希表，分為很多格子，每個格子管理一個行鎖結構鏈表。同一個鏈表的所有行鎖結構，計算得到的哈希值相同。

事務加行鎖時，會優先考慮共用已有的行鎖結構，這就要先找到一個可以共用的行鎖結構。

首先，需要找到 rec_hash 的某個格子。

然后，遍歷這個格子對應的行鎖結構鏈表，并根據共用條件，判斷某個行鎖結構是否可以共用。

事務加行鎖時，如果生成了新的行鎖結構，需要找到 rec_hash 的某個格子，把行鎖結構插入到這個格子對應的行鎖結構鏈表的最前面。

事務提交或回滾時，釋放所有行鎖，需要找到每個鎖結構在哪個格子對應的行鎖結構鏈表中，并從鏈表中刪除這個行鎖結構。

事務加表鎖時，會遍歷這個表對象的 locks 鏈表，以判斷可以立即獲得表鎖，還是需要進入等待狀態。

事務提交或回滾時，釋放所有表鎖，需要從每個表對象的 locks 鏈表中刪除這個表鎖結構。

多個事務執行上面這些操作，可能會同時讀寫 rec_hash 中某個格子對應的行鎖結構鏈表，也可能同時讀寫某個表對象的 locks 鏈表。

為了避免并發操作同時讀寫同一個行鎖結構鏈表、或者同時讀寫同一個表對象的 locks 鏈表出現沖突，需要有個什么東西，來限制同一時刻只有一個事務讀寫某個行鎖結構鏈表、或者某個表對象的 locks 鏈表。

于是，就有了鎖模塊結構的 latches 屬性，它的類型為 locksys::Latches。

class Latches {private:...Unique_sharded_rw_lock global_latch;Page_shards page_shards;Table_shards table_shards;...
}

latches 也是一個對象，有三個屬性，分別為 global_latch、page_shards、table_shards。

事務提交或回滾時，釋放所有行鎖和表鎖會用到 global_latch。

事務加行鎖時，會用到 page_shards。

事務加表鎖時，會用到 table_shards。

page_shards、table_shards 的類型分為 Page_shards、Table_shards，定義如下：

static constexpr size_t SHARDS_COUNT = 512;class Page_shards {...Padded_mutex mutexes[SHARDS_COUNT];...
}class Table_shards {...Padded_mutex mutexes[SHARDS_COUNT];...
}

Page_shards 的 mutexes 屬性是個數組，有 512 個元素。

有新的行鎖結構需要加入某個行鎖結構鏈表，或者需要遍歷某個行鎖結構鏈表以找到目標行鎖結構時，會根據行鎖結構中那些記錄所屬數據頁的頁號和表空間 ID，計算得到哈希值，再根據哈希值計算得到數組下標，到 mutexes 數組中拿到下標對應的互斥量，就可以保護需要讀寫的行鎖結構鏈表了。

Table_shards 的 mutexes 屬性也是個數組，同樣有 512 個元素。

某個表對象的 locks 鏈表需要保護時，會直接用表 ID 對 512 取模（table_id % 512），得到的結果作為數組下標，到 mutexes 數組中拿到下標對應的互斥量，就可以保護這個表對象的 locks 鏈表了。

2.3 鎖等待了怎么辦？

鎖模塊結構中，有三個屬性和鎖等待相關，分別是 wait_mutex、waiting_threads、last_slot，它們的初始化代碼如下：

void lock_sys_create(ulint n_cells)
{ulint lock_sys_sz;// 鎖模塊結構占用的內存大小// 加上 waiting_threads 指向的內存區域的大小// 因為這兩部分要一起分配內存lock_sys_sz = sizeof(*lock_sys) + srv_max_n_threads * sizeof(srv_slot_t);...void *ptr = &lock_sys[1];lock_sys->waiting_threads = static_cast<srv_slot_t *>(ptr);// 初始化時// last_slot 和 waiting_threads 指向同一個位置lock_sys->last_slot = lock_sys->waiting_threads;mutex_create(LATCH_ID_LOCK_SYS_WAIT, &lock_sys->wait_mutex);...
}

waiting_threads 屬性是個指針，它指向一片內存區域，這片內存區域分為 srv_max_n_threads 個 slot，每個 slot 存放一個 srv_slot_t 對象。

srv_max_n_threads 在 innodb_init_params() 中賦值，硬編碼為 102400。

也就是說，waiting_threads 屬性指向的內存區域，最多可以存放 102400 個 srv_slot_t 對象。

如果某個事務不能立即獲得鎖（表鎖或行鎖），就會在這片內存區域中找到一個空閑的 slot，構造一個包含該事務以及鎖信息的 srv_slot_t 對象放入這個 slot，并標記這個 slot 為已使用狀態。

last_slot 屬性也是個指針，初始化時，和 waiting_threads 屬性指向相同的內存地址。

隨著不斷有事務進入鎖等待狀態、以及處于鎖等待狀態的事務獲得鎖，last_slot 會不斷變化。

不過，不管怎么變化，last_slot 始終遵循一個原則，就是它指向的那個 slot，以及之后的所有 slot 都處于空閑狀態。

為什么需要 last_slot？

因為后臺線程檢查鎖等待是否超時，會從后往前遍歷 waiting_threads 屬性指向的內存區域。

如果沒有 last_slot，每次遍歷都需要從最后一個 slot 開始，到第一個 slot 為止，檢查每個 slot 對應的鎖等待是否超時。

然而，通常情況下，waiting_threads 屬性指向的內存區域中的 102400 個 slot，其中大部分都是空閑的。

空閑 slot 沒有被正在等待鎖的事務占用，實際上不需要檢查鎖等待是否超時。

如果沒有 last_slot，每次檢查鎖等待是否超時，都要遍歷所有 slot，顯然很浪費時間。

為了提升檢查鎖等待超時的效率，只需要遍歷已使用狀態的 slot 就可以了，這就需要有個東西來標識哪個范圍內的 slot 是已使用狀態，于是，就有了 last_slot。

有一點需要說明，如果某個事務曾經進入過鎖等待狀態，占用了某個 slot。某一輪檢查鎖等待超時之前，這個事務獲得了鎖，又會把它占用的那個 slot 重置為空閑狀態。

所以，last_slot 之前的那些 slot，并不全部是已使用狀態，也有一些是空閑的，但是這個數量應該不會很多，遍歷這些少量的空閑 slot，也不會浪費太多時間。

介紹完 waiting_threads、last_slot，終于輪到 wait_mutex 屬性了。

從屬性名上看，wait_mutex 屬性顯然是個互斥量。

多個事務同時讀寫 last_slot 屬性，可能造成沖突，這就需要有個東西來保證同一時刻只有一個線程讀寫 last_slot 屬性，于是就有了 wait_mutex。

2.4 那就發個鎖等待通知

事務想要加鎖（表鎖或行鎖），如果發生了鎖等待，新出現的鎖等待，和原來那些鎖等待攪和在一起，有可能會出現死鎖。

為了及時發現死鎖，事務進入鎖等待狀態之前，會觸一個事件，通知后臺線程出現了鎖等待。

這個事件就保存在鎖模塊結構的 timeout_event 屬性中。

監聽 timeout_event 事件的后臺線程收到通知之后，就會開始檢查是否發生了死鎖。如果檢查發現了死鎖，就及時解決。

3. 總結

鎖模塊結構的 rec_hash 屬性是個哈希表，分為很多小格子，每個格子管理一個行鎖結構鏈表。

latches 屬性用于保證同一時刻只有一個線程讀寫 rec_hash 屬性的同一個格子對應的行鎖結構鏈表，以及同一時刻只有一個線程讀寫同一個表對象的 locks 鏈表。

waiting_threads 屬性指向一片分為 102400 個 slot 的內存區域，每個等待獲得鎖的事務會占用其中一個 slot。

last_slot 屬性用于減少檢查鎖等待超時需要遍歷的 slot 數量，提升效率。

wait_mutex 屬性用于保證同一時刻只有一個線程讀寫 last_sot 屬性。

timeout_event 屬性用于發生鎖等待時，通知后臺線程及時檢查是否出現了死鎖。

更多技術文章，請訪問：https://opensource.actionsky.com/

關于 SQLE

SQLE 是一款全方位的 SQL 質量管理平臺，覆蓋開發至生產環境的 SQL 審核和管理。支持主流的開源、商業、國產數據庫，為開發和運維提供流程自動化能力，提升上線效率，提高數據質量。

? Github：https://github.com/actiontech/sqle

📚 文檔：https://actiontech.github.io/sqle-docs/

💻 官網：https://opensource.actionsky.com/sqle/

👥 微信群：請添加小助手加入 ActionOpenSource

🔗 商業支持：https://www.actionsky.com/sqle