一、譯文

If you query data and then insert or update related data within the same transaction, the regular SELECT statement does not give enough protection. Other transactions can update or delete the same rows you just queried. InnoDB supports two types of locking reads that offer extra safety:

如果你在查詢資料，然後在同一個事務裡插入或者修改相關的資料，常規的 select 語句不會提供足夠的保護。其他的事務可以修改或者刪除你正在查詢的行。InnoDB 支援兩種可以提供安全機制的讀取鎖：

SELECT … LOCK IN SHARE MODE sets a shared mode lock on any rows that are read. Other sessions can read the rows, but cannot modify them until your transaction commits. If any of these rows were changed by another transaction that has not yet committed, your query waits until that transaction ends and then uses the latest values.

SELECT … LOCK IN SHARE MODE 在讀取的行上設定一個共享鎖，其他的session可以讀這些行，但在你的事務提交之前不可以修改它們。如果這些行裡有被其他的還沒有提交的事務修改，你的查詢會等到那個事務結束之後使用最新的值。

For index records the search encounters, SELECT … FOR UPDATE locks the rows and any associated index entries, the same as if you issued an UPDATE statement for those rows. Other transactions are blocked from updating those rows, from doing SELECT … LOCK IN SHARE MODE, or from reading the data in certain transaction isolation levels. Consistent reads ignore any locks set on the records that exist in the read view. (Old versions of a record cannot be locked; they are reconstructed by applying undo logs on an in-memory copy of the record.)

索引搜尋遇到的記錄，SELECT … FOR UPDATE 會鎖住行及任何關聯的索引條目，和你對那些行執行 update 語句相同。其他的事務會被阻塞在對這些行執行 update 操作，獲取共享鎖，或從某些事務隔離級別讀取資料等操作。一致性讀(Consistent Nonlocking Reads)會忽略在讀取檢視上的記錄的任何鎖。（舊版本的記錄不能被鎖定；它們通過應用撤銷日誌在記錄的記憶體副本上時被重建。）

All locks set by LOCK IN SHARE MODE and FOR UPDATE queries are released when the transaction is committed or rolled back.

Note
Locking of rows for update using SELECT FOR UPDATE only applies when autocommit is disabled (either by beginning transaction with START TRANSACTION or by setting autocommit to 0. If autocommit is enabled, the rows matching the specification are not locked.

所有被共享鎖和排他鎖查詢所設定的鎖都會在事務提交或者回滾之後被釋放。

注:
使用 SELECT FOR UPDATE 為 update 操作鎖定行，只適用於 autocommit 被禁用（當使用 START TRANSACTION 開始事務或者設定 autocommit 為0時）。如果 autocommit 已啟用，符合規範的行不會被鎖定。

二、總結

SELECT … LOCK IN SHARE MODE ：共享鎖(S鎖, share locks)。其他事務可以讀取資料，但不能對該資料進行修改，直到所有的共享鎖被釋放。

如果事務對某行資料加上共享鎖之後，可進行讀寫操作；其他事務可以對該資料加共享鎖，但不能加排他鎖，且只能讀資料，不能修改資料。

SELECT … FOR UPDATE：排他鎖(X鎖, exclusive locks)。如果事務對資料加上排他鎖之後，則其他事務不能對該資料加任何的鎖。獲取排他鎖的事務既能讀取資料，也能修改資料。

注：普通 select 語句預設不加鎖，而CUD操作預設加排他鎖。

三、驗證

注：使用 mysql 版本為 5.7.9，事務隔離級別為InnoDB預設隔離級別 可重複讀(Repeated Read)。

對以下幾種情況進行驗證：

1. 當前事務獲取共享鎖後，可以讀寫，其他事務是否可以進行讀寫操作和獲取共享鎖；
2. 兩個事務同時獲取共享鎖後，是否可以進行update操作；
3. 當前事務獲取排他鎖後，其他事務是否可以進行讀寫操作和獲取共享鎖；
4. 是否可對一條資料加多個排他鎖；
5. 行鎖和索引的關係；
6. 索引資料重複率太高會導致全表掃描；

1、當前事務獲取共享鎖後，可以讀寫，其他事務是否可以進行讀寫操作和獲取共享鎖：可以讀，可以獲取共享鎖，不可以寫

當前事務可以寫：

事務1獲取某行資料共享鎖後，事務2更新該行阻塞:

事務1提交之後，事務2更新成功：

2、兩個事務同時獲取某行資料共享鎖後，是否可以進行update操作：不可以

兩個事務同時獲取某行資料共享鎖，事務1更新該行阻塞：

事務2提交之後，事務1更新成功：

3、當前事務獲取某行資料排他鎖後，其他事務是否可以對該行資料進行讀寫操作和獲取共享鎖：其他事務可以讀，不可以獲取共享鎖，不可以寫

可以讀該行資料：

不可以獲取該行資料共享鎖：

不可以更新該行資料：

4、是否可對一條資料加多個排他鎖：不可以

5、行鎖和索引的關係：查詢欄位未加索引（主鍵索引、普通索引等）時，使用表鎖

注：InnoDB行級鎖基於索引實現。

未加索引時，兩種行鎖情況為（使用表鎖）：
- 事務1獲取某行資料共享鎖，其他事務可以獲取不同行資料的共享鎖，不可以獲取不同行資料的排他鎖
- 事務1獲取某行資料排他鎖，其他事務不可以獲取不同行資料的共享鎖、排他鎖

加索引後，兩種行鎖為（使用行鎖）：

• 事務1獲取某行資料共享鎖，其他事務可以獲取不同行資料的排他鎖
• 事務1獲取某行資料排他鎖，其他事務可以獲取不同行資料的共享鎖、排他鎖

未加索引表結構：

未加索引，事務1獲取某行資料共享鎖，事務2獲取不同行資料共享鎖成功：

未加索引，事務1獲取某行資料共享鎖，事務2更新不同行資料阻塞：

未加索引，事務1獲取某行資料排他鎖，事務2獲取不同行資料共享鎖阻塞：

未加索引，事務1獲取某行資料排他鎖，事務2獲取不同行資料排他鎖阻塞：

加索引後表結構：

加索引後，事務1獲取某行資料共享鎖，事務2更新不同行資料成功：

加索引後，事務1獲取某行資料排他鎖，事務2獲取不同行資料共享鎖成功：

加索引後，事務1獲取某行資料排他鎖，事務2獲取不同行資料排他鎖成功：

6、索引資料重複率太高會導致全表掃描：當表中索引欄位資料重複率太高，則MySQL可能會忽略索引，進行全表掃描，此時使用表鎖。可使用 force index 強制使用索引。

表結構：

CREATE TABLE `room` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `uid` int(11) NOT NULL,
  `username` varchar(200) NOT NULL DEFAULT '',
  `state` varchar(255) NOT NULL DEFAULT '-1',
  `created_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `updated_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `index_uid` (`uid`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8

表資料：

獲取 uid = ‘11’ 的資料的行鎖並更新，但更新失敗：

降低資料重複率，更新成功：

強制使用索引，更新成功：force index(index_uid)

注：此處如果使用表鎖，為何其他事務可以獲取排他鎖？

答：由於使用 force index ，而 InnoDB 行級鎖基於索引實現，因此此處使用的是行鎖。

四、InnoDB 行鎖型別簡介

InnoDB行鎖的三種類型：

• Record Lock：對索引項加鎖，鎖定符合條件的行。其他事務不能修改和刪除加鎖項；
• Gap Lock：對索引項之間的“間隙”加鎖，鎖定記錄的範圍，不包含索引項本身。其他事務不能再鎖範圍內插入資料；
• Next-key Lock: 鎖定索引項本身和索引範圍，即Record Lock 和 Gap Lock 的結合。可解決幻讀問題。