记录间隙临键锁

共 20 题
#

1. MySQL InnoDB 临键锁(Next-Key Lock),记录锁 + 间隙锁的组合?

A 临键锁只锁记录本身,不锁间隙
B 临键锁在 READ COMMITTED 下默认启用
C 临键锁与间隙锁无关
D 临键锁是记录锁与间隙锁的组合,锁定左开右闭区间 ✓ 正确答案
#

2. MySQL InnoDB 记录锁(Record Lock),锁定索引记录?

A 记录锁锁定的是索引记录 ✓ 正确答案
B 记录锁锁的是整行数据,而非索引
C 记录锁同时防止间隙插入
D 记录锁与索引无关
#

3. MySQL InnoDB 间隙锁(Gap Lock),锁定索引间隙防止插入?

A 间隙锁锁定记录本身,阻止修改
B 间隙锁之间互相冲突
C 间隙锁锁定索引记录之间的空隙,阻止插入 ✓ 正确答案
D 间隙锁与插入意向锁不冲突
#

4. READ COMMITTED 下 Gap Lock 禁用(外键约束与重复键检查除外)?

A RC 下完全禁用一切间隙锁
B RC 下间隙锁与记录锁都禁用
C RC 下只使用间隙锁,不用记录锁
D RC 下默认禁用间隙锁,但外键约束与重复键检查仍会使用 ✓ 正确答案
#

5. REPEATABLE READ 下 Next-Key Lock 的应用,防止幻读?

A RR 下普通 SELECT 也加临键锁
B RR 下不使用任何锁
C RR 下加锁读用临键锁锁定记录与间隙,防止幻读 ✓ 正确答案
D RR 下临键锁只锁记录不锁间隙
#

6. Next-Key Lock 的组成,记录锁+间隙锁如何锁住范围?

A 只由间隙锁组成
B 由表锁加行锁组成
C 只由记录锁组成
D 由记录锁加间隙锁组成,锁定左开右闭区间 ✓ 正确答案
#

7. 为什么 RR 隔离级别下普通 SELECT 不加锁(快照读),而 SELECT ... FOR UPDATE/UPDATE/DELETE 才加临键锁(当前读)

A 普通 SELECT 是快照读不加锁,UPDATE/FOR UPDATE 是当前读加临键锁 ✓ 正确答案
B 普通 SELECT 也加临键锁
C 所有读操作都加锁
D 快照读与当前读都加锁
#

8. 范围查询(>=、>、BETWEEN)的临键锁边界与锁区间推导

A WHERE id >= 20 会锁 (10,20]、(20,30] 及上界间隙 ✓ 正确答案
B 范围查询只锁命中的记录,不锁间隙
C BETWEEN 不会加间隙锁
D 范围查询不会加锁
#

9. 唯一索引等值查询仅使用 Record Lock 的特例?

A 唯一索引等值查询永远加临键锁
B 命中记录时退化为仅记录锁,不锁间隙 ✓ 正确答案
C 只有非唯一索引才加记录锁
D 唯一索引等值查询不加任何锁
#

10. 插入意向锁(Insert Intention Lock)的应用,多事务并发插入?

A 插入意向锁之间互斥,串行插入
B 插入意向锁只在读操作时使用
C 插入意向锁与间隙锁不冲突
D 插入意向锁之间不冲突,但与间隙锁冲突时等待 ✓ 正确答案
#

11. Gap Lock 的性能影响?

A 间隙锁只锁单条记录,不影响并发
B 间隙锁扩大锁范围并阻塞插入,降低并发度 ✓ 正确答案
C 间隙锁提高并发插入能力
D 间隙锁与性能无关
#

12. 间隙锁的冲突,为什么间隙锁之间不互斥,与插入意向锁的协作?

A 间隙锁之间互斥,与插入意向锁也互斥
B 插入意向锁之间互斥
C 间隙锁与一切锁都不冲突
D 间隙锁之间不互斥,但与插入意向锁冲突 ✓ 正确答案
#

13. 临键锁与唯一索引,唯一键冲突时的加锁与死锁?

A 唯一键冲突检查会对重复记录加共享锁,并发插入可能产生死锁 ✓ 正确答案
B 唯一键冲突不会加锁,直接报错
C 唯一键冲突只加排他锁
D 唯一键冲突不会产生死锁
#

14. 外键约束检查触发的共享锁与子表插入时的锁等待

A 外键检查不加锁,只做逻辑判断
B 外键检查只加排他锁
C 子表插入会检查父表记录并加共享锁,可能产生锁等待 ✓ 正确答案
D 外键检查不会产生任何锁等待
#

15. 间隙锁与插入意向锁交互导致的死锁案例与日志解读

A 间隙锁与插入意向锁不会产生死锁
B 事务各自持有间隙锁并等待对方间隙插入,会形成死锁 ✓ 正确答案
C 死锁只能靠人工解锁
D InnoDB 不会自动检测死锁
#

16. InnoDB 对二级索引与聚簇索引的加锁顺序(先二级索引再回表加主键锁)与死锁的关系

A 先加聚簇索引锁,再回表加二级索引锁
B 二级索引不加锁
C 一次只加一个锁,无顺序问题
D 先加二级索引锁,再回表加聚簇索引锁,顺序不一致易死锁 ✓ 正确答案
#

17. 如何查看与减少间隙锁,RR 下的范围查询加锁分析?

A 间隙锁无法查看
B 间隙锁只能靠重启清除
C 可通过 performance_schema 查看,改用 RC 级别或唯一索引可减少间隙锁 ✓ 正确答案
D 减少间隙锁与隔离级别无关
#

18. 如何验证加锁范围,performance_schema 与锁监控?

A 只能通过重启验证
B 只有 EXPLAIN 能验证锁
C 加锁范围无法观测
D 可通过 performance_schema 的 data_locks/data_lock_waits 查看锁范围与等待 ✓ 正确答案
#

19. 如何通过 EXPLAIN/锁监控确认 UPDATE 实际锁定的索引范围

A EXPLAIN 查访问计划,锁监控确认实际加锁范围,无索引的 UPDATE 会大范围加锁 ✓ 正确答案
B EXPLAIN 直接显示实际锁范围
C UPDATE 从不加锁
D 锁范围与索引无关
#

20. 锁等待超时的观测(information_schema.INNODB_TRX 与 performance_schema.data_lock_waits)

A innodb_trx 与 data_lock_waits 结合可定位阻塞链与阻塞源事务 ✓ 正确答案
B 锁等待超时无法观测
C 只需重启数据库即可解决
D innodb_lock_wait_timeout 控制的是死锁检测