1. 准备工作
创建测试表：
复制
CREATE TABLE `t1` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`i1` int DEFAULT 0,
PRIMARY KEY (`id`) USING BTREE,
KEY `idx_i1` (`i1`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3;1.2.3.4.5.6.
插入测试数据：
复制
INSERT INTO `t1` (`id`, `i1`) VALUES
(10, 101), (20, 201), (30, 301), (40, 401);1.2.
2. 可重复读
把事务隔离级别设置为 REPEATABLE-READ（如已设置，忽略此步骤）：
复制
SET transaction_isolation = REPEATABLE-READ;
-- 确认设置成功
SHOW VARIABLES like transaction_isolation;
+-----------------------+-----------------+
| Variable_name | Value |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+1.2.3.4.5.6.7.8.9.
执行以下 select 语句：
复制
begin;
select * from t1 ignore index(idx_i1)
where id >= 10 and id < 30 for share;1.2.3.
查看加锁情况：
复制
select
engine_transaction_id, object_name, index_name,
lock_type, lock_mode, lock_status, lock_data
from performance_schema.data_locks
where object_name = t1
and lock_type = RECORD\G
***************************[ 1. row ]***************************
engine_transaction_id | 281479856983976
object_name | t1
index_name | PRIMARY
lock_type | RECORD
lock_mode | S,REC_NOT_GAP
lock_status | GRANTED
lock_data | 10
***************************[ 2. row ]***************************
engine_transaction_id | 281479856983976
object_name | t1
index_name | PRIMARY
lock_type | RECORD
lock_mode | S
lock_status | GRANTED
lock_data | 20
***************************[ 3. row ]***************************
engine_transaction_id | 281479856983976
object_name | t1
index_name | PRIMARY
lock_type | RECORD
lock_mode | S,GAP
lock_status | GRANTED
lock_data | 301.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.
lock_data = 10、lock_mode = S,REC_NOT_GAP 表示对主键索引中 <id = 10> 的记录加了共享普通记录锁。
没有按照默认行为加共享 Next-Key 锁，是因为示例 SQL 使用主键索引进行范围扫描，从 <id = 10> 的记录开始，不关心它前面的记录。
示例 SQL 并不在意其它事务往 <id = 10> 的记录前面插入什么记录，不需要锁住它前面的间隙，加普通记录锁就可以了。
如果有其它事务往 <id = 10> 的记录前面的间隙插入记录，示例 SQL 还能保证可重复读吗？
这个是没问题的。
因为其它事务往 <id = 10> 的记录前面的间隙插入记录，这些记录的 id 字段值一定小于 10，在示例 SQL 的 where 条件覆盖范围之外，不影响示例 SQL 的可重复读。
其它事务要往 t1 表中插入记录，id 大于等于 10、小于等于 19 的记录都会插入到 <id = 10> 和 <id = 20> 之间的间隙。这个间隙不归 <id = 10> 的记录上的锁管辖。
当然了，因为存在主键索引，t1 表中 <id = 10> 的记录删除之前，其它事务想要再插入 <id = 10> 的记录是不可能的。
lock_data = 20、lock_mode = S 表示对主键索引中 <id = 20> 的记录加了共享 Next-Key 锁，这是可重复读隔离级别下的默认行为，不多解释。
lock_data = 30、lock_mode = S,GAP 表示对主键索引中 <id = 30> 的记录加了共享间隙锁。
没有按照默认行为加共享 Next-Key 锁，是因为 <id = 30> 的记录位于示例 SQL 的 where 条件覆盖范围之外。
示例 SQL 不关心 <id = 30> 的记录本身，只需要保证其它事务不能往这条记录前面的间隙插入记录，加共享间隙加就满足需求了。
3. 读已提交
把事务隔离级别设置为 READ-COMMITTED（如已设置，忽略此步骤）：
复制
SET transaction_isolation = READ-COMMITTED;
-- 确认设置成功
SHOW VARIABLES like transaction_isolation;
+-----------------------+----------------+
| Variable_name | Value |
+-----------------------+----------------+
| transaction_isolation | READ-COMMITTED |
+-----------------------+----------------+1.2.3.4.5.6.7.8.9.
执行以下 select 语句：
复制
begin;
select * from t1 ignore index(idx_i1)
where id >= 10 and id < 30 for share;1.2.3.
查看加锁情况：
复制
select
engine_transaction_id, object_name, index_name,
lock_type, lock_mode, lock_status, lock_data
from performance_schema.data_locks
where object_name = t1
and lock_type = RECORD\G
***************************[ 1. row ]***************************
engine_transaction_id | 281479856983976
object_name | t1
index_name | PRIMARY
lock_type | RECORD
lock_mode | S,REC_NOT_GAP
lock_status | GRANTED
lock_data | 10
***************************[ 2. row ]***************************
engine_transaction_id | 281479856983976
object_name | t1
index_name | PRIMARY
lock_type | RECORD
lock_mode | S,REC_NOT_GAP
lock_status | GRANTED
lock_data | 201.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.
lock_data = 10、lock_mode = S,REC_NOT_GAP 表示对主键索引中 <id = 10> 的记录加了共享普通记录锁，这是读已提交隔离级别的默认行为，不多解释。
lock_data = 20、lock_mode = S,REC_NOT_GAP 表示对主键索引中 <id = 20> 的记录加了共享普通记录锁，这是读已提交隔离级别的默认行为，不多解释。
可重复读隔离级别对主键索引中 <id = 30> 的记录加了锁，读已提交隔离级别为什么没有对主键索引中 <id = 30> 的记录加锁呢？
其实读已提交隔离级别下，InnoDB 从主键索引中读取 <id = 30> 的记录之后，也会加共享普通记录锁。
InnoDB 把这条记录返回给 server 层之后，server 层判断这条记录不匹配 where 条件，会通知 InnoDB 释放这条记录上刚刚加的共享普通记录锁。
我们最终看到的结果就是示例 SQL 没有对主键索引中 <id = 30> 的记录加锁。
这种加了锁又释放的方式，一般情况下没什么影响，但是如果因为这种方式造成了死锁，我们不了解这个逻辑，就会有点摸不着头脑了。
4. 总结
可重复读隔离级别下，对某条记录加了锁，要等到事务提交或者回滚时才释放。
读已提交隔离级别下，对某条记录加了锁，如果 server 层或者 InnoDB 发现记录不匹配 where 条件，会马上释放锁。
