眾所周知，InnoDB 中既有讀鎖也有寫鎖，也稱為共享鎖和排他鎖，這兩種鎖既可以加在整張表上，也可以加在行上。

MySQL 自身就提供了表鎖的能力：

• 讀鎖：LOCK TABLE table_name READ 用讀鎖鎖表，會(huì)阻塞其他事務(wù)的寫操作
• 寫鎖：LOCK TABLE table_name WRITE 用寫鎖鎖表，會(huì)阻塞其他事務(wù)的讀和寫操作

行鎖是 InnoDB 存儲(chǔ)引擎提供的，MySQL 本身并不提供行級(jí)鎖的能力：

• 讀鎖，如SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE 加行級(jí)讀鎖，會(huì)阻塞其他事務(wù)對(duì)該行記錄的寫操作
• 寫鎖，如SELECT * FROM table_name WHERE ... FOR UPDATE 加行級(jí)寫鎖，會(huì)阻塞其他事務(wù)對(duì)該行記錄的的讀和寫操作

又有表鎖又有行鎖，我們來考慮下這兩種類型的鎖共存的問題。看下面這個(gè)例子：

事務(wù) A 加了行級(jí)讀鎖，鎖住了表中的一行，讓這一行只能讀，不能寫。

之后，事務(wù) B 嘗試申請(qǐng)整個(gè)表的寫鎖。

如果事務(wù) B 申請(qǐng)成功，那么理論上它就能修改表中的任意一行，這與 A 持有的行級(jí)讀鎖是沖突的。

數(shù)據(jù)庫需要避免這種沖突，就勢(shì)必要讓 B 的申請(qǐng)被阻塞，直到 A 釋放行級(jí)讀鎖。

那數(shù)據(jù)庫要怎么判斷這個(gè)沖突呢？

• 步驟 1：判斷表是否已被其他事務(wù)用表級(jí)鎖鎖住了整張表
• 步驟 2：判斷表中的每一行是否已被行級(jí)鎖鎖住

看起來沒有什么困難的，但請(qǐng)注意步驟 2，判斷表中的每一行，各位，如何判斷？

顯然，需要遍歷！遍歷表中的每一行。

小學(xué)生都能想到這樣的判斷方法效率實(shí)在太過于低下了。

于是就有了意向鎖！

我們先來看下意向鎖的解釋：

Intention locks are table-level locks that indicate which type of lock (shared or exclusive) a transaction requires later for a row in a table.

意向鎖是一個(gè)表級(jí)鎖，其作用就是指明接下來的事務(wù)將會(huì)用到哪種鎖。

有兩種意向鎖：

• 意向共享鎖/讀鎖（IS Lock）：當(dāng)事務(wù)想要獲得一張表中某幾行的讀鎖（行級(jí)讀鎖）時(shí)，InnoDB 存儲(chǔ)引擎會(huì)自動(dòng)地先獲取該表的意向讀鎖（表級(jí)鎖）
• 意向排他鎖/寫鎖（IX Lock）：當(dāng)事務(wù)想要獲得一張表中某幾行的寫鎖（行級(jí)寫鎖）時(shí)，InnoDB 存儲(chǔ)引擎會(huì)自動(dòng)地先獲取該表的意向?qū)戞i（表級(jí)鎖）

注意這里的自動(dòng)：申請(qǐng)意向鎖的動(dòng)作是數(shù)據(jù)庫完成的，就是說，事務(wù) A 申請(qǐng)一行的行鎖的時(shí)候，數(shù)據(jù)庫會(huì)自動(dòng)先開始申請(qǐng)表的意向鎖，不需要我們程序員使用代碼來申請(qǐng)。

在意向鎖存在的情況下，事務(wù) A 如果想申請(qǐng)行級(jí)讀鎖，就必須先申請(qǐng)?jiān)摫淼囊庀蜃x鎖，申請(qǐng)成功后才能繼續(xù)申請(qǐng)某行記錄的行級(jí)讀鎖。

在意向鎖存在的情況下，上面的判斷可以改成：

• 步驟 1（不變）：判斷表是否已被其他事務(wù)用表級(jí)鎖鎖住了整張表
• 步驟 2：發(fā)現(xiàn)表上有意向讀鎖（說明表中有些行被行級(jí)讀鎖鎖住了），意向讀鎖和表級(jí)寫鎖互斥，因此，事務(wù) B 申請(qǐng)表的寫鎖會(huì)被阻塞。

也就是說原先步驟 2 的遍歷表中每一行的操作，簡(jiǎn)化成了判斷下整張表上有無表級(jí)意向鎖就行了，效率大幅提升。

這就是為什么要有意向鎖了。