InnoDB 存儲引擎支持多粒度鎖(multiple granularity locking)，也就是允許行鎖和表鎖共存。當允許行鎖和表鎖共存的時候，可能會存在下面這樣一個問題：

例如我執(zhí)行如下 SQL：

這段 SQL 執(zhí)行完成后，給 id 為 1 的記錄加了排他鎖。

此時，在另外一個會話中，我如果想給這張表再來一個表級共享鎖，如下：

lock table user read;

此時就會有一個問題，共享鎖和排他鎖是互斥的，要給表上共享鎖，就得去檢查一下表中的每一條記錄都不存在排他鎖，如果表中的數(shù)據(jù)量比較大，這個操作效率就會比較低。

為了解決這個問題，就引出了我們今天的意向鎖。為了使多粒度級別的鎖定變得實用，InnoDB 使用了意向鎖，注意，意向鎖是一種表級鎖，它表示事務稍后對表中的行需要哪種類型的鎖(共享或獨占)。

意向鎖也分為兩類：

• intention shared lock：意向共享鎖 (IS) 表示事務打算在表中的各個行上設置共享鎖。
• intention exclusive lock：意向排他鎖 (IX) 表示事務打算對表中的各個行設置排他鎖。

例如，對于 SELECT ... LOCK IN SHARE MODE; 會自動設置 IS 鎖，對于 SELECT ... FOR UPDATE 會自動設置 IX 鎖，并且 IS 鎖和 IX 鎖不需要手動設置，這個是由系統(tǒng)自動設置。

意向鎖的加鎖規(guī)則如下：

• 在事務可以獲取表中行的共享鎖之前，它必須首先獲取表上的 IS 鎖或更強的鎖。
• 在事務可以獲取表中行的排他鎖之前，它必須首先獲取表上的 IX 鎖。

簡而言之：IS 和 IX 是表鎖，它們存在的意義在于，將來給表上表級的 S 鎖或者 X 鎖的時候，可以通過 IS 或者 IX 快速判斷出當前表中是否已經(jīng)有加鎖記錄了，僅此而已。所以 IS 和 IX 之間其實是兼容的，IX 之間也是兼容的，如下表：

但是意向鎖和表級鎖則有可能沖突，如下：

上面這張表也好理解：

• 如果表上有 IS，說明表中的記錄有共享鎖，此時就不可以給表加排他鎖(X 鎖)，但是可以給表加共享鎖(S 鎖)。
• 如果表上有 IX，說明表中的記錄有排他鎖，此時就不可以給表加排他鎖(X 鎖)，也不可以給表加共享鎖(S 鎖)。

整體上來說，兼容關系如下表：

由于意向鎖并不需要我們手動添加，那么有沒有辦法讓我們看到意向鎖呢？可以的。

首先我們將系統(tǒng)變量 innodb_status_output_locks 設置為 ON，如下：

接下來我們執(zhí)行如下 SQL，鎖定一行數(shù)據(jù)，此時會自動為表加上 IX 鎖：

接下來我們在一個新的會話中執(zhí)行如下指令來查看 InnoDB 存儲引擎的情況：

show engine innodb status\G

輸出的信息很多，我們重點關注 TRANSACTIONS，如下：

可以看到：

• TABLE LOCK table test08.user trx id 3564804 lock mode IX：這句就是說事務 id 為 3564804 的事務，為 user 表添加了意向排他鎖(IX)。
• RECORD LOCKS space id 851 page no 3 n bits 80 index PRIMARY of table test08.user trx id 3564804 lock_mode X locks rec but not gap：這個就是一個鎖結構的記錄，這里的索引是 PRIMARY，加的鎖也是正兒八經(jīng)的記錄鎖(not gap)，因為索引是 PRIMARY，所以這里沒有間隙鎖，關于間隙鎖，咱們下篇文章繼續(xù)。

好啦，希望今天這篇文章能讓小伙伴們對意向鎖有一個簡單的認知。