锁与并发控制
061 共享锁（S 锁）与排他锁（X 锁）的关系是？
难度： 基础
- A. S 锁之间兼容，S 锁与 X 锁、X 锁与 X 锁互斥
- B. 任意两把 S 锁都互斥，读取必须串行
- C. X 锁之间可以共存，只要行不同
- D. S 锁能阻止其他事务读取同一行
查看答案与解析
正确答案A
正确原因： 共享锁彼此兼容，多个事务可同时读同一行；排他锁与任何锁互斥。
关键边界： 行级 S/X 锁由 InnoDB 自动管理，也可用 FOR SHARE、FOR UPDATE 显式请求。
错误选项辨析： S 锁不互斥也不阻止读取，X 锁之间必然互斥。
062 记录锁（Record Lock）锁定的对象是？
难度： 基础
- A. 索引记录本身（一行）
- B. 整张表的全部行
- C. 索引中一段连续区间
- D. 尚未插入的“空位”
查看答案与解析
正确答案A
正确原因： 记录锁锁定具体的索引记录，即一行。
关键边界： 间隙锁锁定区间空位，表锁才锁定整表。
错误选项辨析： 锁整表是表锁，锁区间是间隙锁或临键锁。
063 间隙锁（Gap Lock）的作用是？
难度： 基础
- A. 锁定已经存在的行并阻止更新
- B. 锁定索引区间内的“间隙”，阻止其他事务在范围内插入新行，防幻读
- C. 把整个表锁定，禁止一切读写
- D. 只对 MyISAM 表生效
查看答案与解析
正确答案B
正确原因： 间隙锁锁住记录之间的空位，阻止其他事务在区间内插入。
关键边界： RR 下范围查询默认使用间隙锁，RC 下主要用于外键与唯一性检查。
错误选项辨析： 间隙锁不锁已有行，不锁整表，且只存在于 InnoDB。
064 临键锁（Next-Key Lock）由什么组成？
难度： 基础
- A. 两个记录锁叠加
- B. 记录锁加间隙锁，锁定记录及其前面的间隙
- C. 表锁加行锁
- D. 唯一主键上的间隙锁
查看答案与解析
正确答案B
正确原因： Next-Key Lock 是记录锁与其前间隙锁的组合，是 RR 下范围扫描的默认锁。
关键边界： 唯一索引等值命中时退化为记录锁，不锁间隙。
错误选项辨析： 它不是两个记录锁，不是表锁，也不局限于唯一主键。
065 意向锁（Intention Lock）存在的意义是？
难度： 基础
- A. 直接锁定所有行数据
- B. 阻止其他事务读取表结构
- C. 让表级锁与行级锁快速判断兼容性，避免逐行检查
- D. 只在 SERIALIZABLE 下出现
查看答案与解析
正确答案C
正确原因： 事务加行锁前先声明表级意向锁，表锁请求者可据此快速判断冲突。
关键边界： 意向锁（IS/IX）本身不阻塞其他事务的正常读写。
错误选项辨析： 意向锁不锁行，不锁表结构，任何隔离级别加行锁时都会使用。
066 自增锁（AUTO-INC Lock）在 MySQL 8.0 默认模式下的行为是？
难度： 基础
- A. 必须持有表级锁直到事务提交
- B. 自增值允许回滚复用
- C. 简单插入使用轻量互斥即可分配自增值，不持表级锁到事务结束
- D. 自增列在 8.0 已被废弃
查看答案与解析
正确答案C
正确原因： 8.0 默认 autoinc_lock_mode=2 交错分配，简单插入不锁表，性能更好。
关键边界： 该模式下自增值可能不连续，binlog 需 row 格式保证复制一致。
错误选项辨析： 锁表直到提交是模式 0 或 1 的行为，自增值不会回滚复用，自增列仍广泛使用。
067 死锁产生的必要条件是？
难度： 基础
- A. 只有一个事务执行写操作
- B. 所有事务都只读
- C. 磁盘空间不足
- D. 多个事务以不同顺序持有并等待资源，形成循环等待
查看答案与解析
正确答案D
正确原因： 死锁需要互斥、持有并等待、不可剥夺与循环等待四个条件同时成立。
关键边界： InnoDB 会检测死锁并回滚其中一个事务。
错误选项辨析： 单写者或全只读不会形成循环等待，磁盘空间与死锁无关。
068 SELECT … FOR UPDATE 属于哪种锁机制？
难度： 基础
- A. 乐观锁，不加任何锁
- B. 快照读，读取历史版本
- C. 表级读锁，阻塞所有查询
- D. 悲观锁（当前读），锁定选中行直到事务结束
查看答案与解析
正确答案D
正确原因： FOR UPDATE 是锁定读，对选中行加行级 X 锁（范围可能含间隙）直到事务结束。
关键边界： 用于先查后改场景，事务结束或回滚时释放。
错误选项辨析： 它加锁而非乐观，读最新而非历史版本，锁行而非整表。
069 乐观锁的典型实现方式是？
难度： 进阶
- A. 更新时带版本号或旧状态条件，受影响行数为 0 表示冲突
- B. 先给整张表加写锁再更新
- C. 更新时无条件覆盖，不回读
- D. 使用 SELECT FOR UPDATE 保持锁
查看答案与解析
正确答案A
正确原因： 乐观锁不持锁，靠版本条件保证状态迁移原子性，行数为 0 即冲突。
关键边界： 冲突后由应用重试或返回错误，不能忽略行数检查。
错误选项辨析： 表锁与 FOR UPDATE 都是悲观锁思路，无条件覆盖无法检测冲突。
070 元数据锁（MDL）的作用是？
难度： 进阶
- A. 保护表结构，协调 DDL 与 DML，防止结构变更时读写错乱
- B. 保护磁盘上的数据文件不被删除
- C. 锁定用户密码与权限记录
- D. 只在跨库查询时出现
查看答案与解析
正确答案A
正确原因： MDL 由 Server 层管理，表结构变更与读写请求之间互斥协调。
关键边界： 长查询或长事务持有 MDL 会阻塞后续 DDL，是 ALTER 卡住的常见原因。
错误选项辨析： MDL 不涉及文件删除与账号权限，单库内的 DDL/DML 同样涉及。
071 插入意向锁（Insert Intention Lock）是什么？
难度： 进阶
- A. 一种表级锁，禁止所有插入
- B. 插入前在间隙上声明的意向，多个插入意向锁可共存，但会等待间隙锁释放
- C. 与普通记录锁完全等价
- D. 插入后立即升级为全表锁
查看答案与解析
正确答案B
正确原因： 插入意向锁彼此兼容，同一间隙可并发插入不同位置，但需要等待占用该间隙的间隙锁释放。
关键边界： 它只在插入前声明，是间隙锁与插入操作之间的协调机制。
错误选项辨析： 它不锁表、不等价于记录锁，也不会升级为表锁。
072 InnoDB 检测到死锁后的处理是？
难度： 进阶
- A. 随机重启整个数据库实例
- B. 选择回滚代价较小的事务并抛出错误，另一事务继续执行
- C. 把所有事务全部回滚并清空数据
- D. 永久阻塞，等待 DBA 手工处理
查看答案与解析
正确答案B
正确原因： 死锁检测发现循环等待后回滚其中一个事务，应用捕获错误后重试。
关键边界： 锁等待超时（innodb_lock_wait_timeout）是兜底机制，死锁检测通常提前介入。
错误选项辨析： 死锁处理不重启实例、不清理数据，也不会永久阻塞。
073 innodb_lock_wait_timeout 控制的是？
难度： 进阶
- A. 事务总执行时间上限
- B. 慢查询记录阈值
- C. 事务等待锁的最长时间，超时返回锁等待超时错误
- D. 连接空闲断开时间
查看答案与解析
正确答案C
正确原因： 该参数限制锁等待时长，超时返回 1205 错误。
关键边界： 死锁检测与锁等待超时是两个机制，应用需设计对应重试。
错误选项辨析： 它不管总执行时间、慢查询与连接空闲。
074 与 REPEATABLE READ 相比，READ COMMITTED 下 InnoDB 的间隙锁？
难度： 进阶
- A. 间隙锁更多，防幻读更彻底
- B. 完全取消所有锁，改为纯版本控制
- C. 默认不再为普通范围查询加间隙锁，幻读可能发生
- D. 只在唯一索引上使用间隙锁
查看答案与解析
正确答案C
正确原因： RC 下普通查询不加间隙锁，锁更少、死锁概率更低，但范围结果可能变化。
关键边界： RC 下 binlog 需使用 row 格式，且间隙锁仍用于外键与唯一性检查。
错误选项辨析： RC 的间隙锁更少而非更多，写操作仍要加记录锁。
075 唯一索引冲突插入时，InnoDB 会做什么？
难度： 进阶
- A. 不加任何锁，直接返回成功
- B. 永久删除已存在的行
- C. 锁住整张表直到重启
- D. 对已存在的重复记录加锁（可能升级为 X 锁），处理插入等待场景
查看答案与解析
正确答案D
正确原因： 冲突插入会对目标记录加锁再检查，可能等待删除该记录的事务，是死锁高发点。
关键边界： 具体锁类型取决于隔离级别与冲突场景，处理逻辑较为复杂。
错误选项辨析： 冲突不会成功，不会删除已有行，也不会锁整表。
076 普通 SELECT 与 SELECT … FOR UPDATE 的并发表现差异是？
难度： 进阶
- A. 普通 SELECT 会阻止其他事务写入
- B. FOR UPDATE 不影响任何其他事务
- C. 普通 SELECT 必须等待所有写提交
- D. 普通 SELECT 不阻塞任何事务；FOR UPDATE 会阻塞冲突写与锁定读
查看答案与解析
正确答案D
正确原因： MVCC 让普通读不加锁，锁定读则进入锁队列，与写操作互斥。
关键边界： 快照读对已提交但未刷盘的数据也可见，而当前读必须拿到最新版本。
错误选项辨析： 普通读不阻塞写，FOR UPDATE 会互斥，普通读无需等待写提交。
077 秒杀扣库存场景，选择行锁方案时最需要注意什么？
难度： 实战
- A. 控制事务长度、按统一顺序访问并处理锁等待与死锁重试
- B. 事务越长越好，可减少锁冲突
- C. 扣减前先 SLEEP 保证公平
- D. 死锁无需处理，数据库会保留所有请求
查看答案与解析
正确答案A
正确原因： 行锁并发下长事务放大等待窗口，热点行仍有串行瓶颈。
关键边界： 可结合队列、预扣减或异步削峰降低数据库压力。
错误选项辨析： 长事务加剧冲突，SLEEP 不解决公平，死锁必须由应用重试。
078 排查线上死锁，首先应该做什么？
难度： 实战
- A. 直接重启数据库清空锁信息
- B. 用 SHOW ENGINE INNODB STATUS 查看最近死锁涉及的锁与 SQL 信息
- C. 删除全部索引改为全表扫描
- D. 把隔离级别改为 READ UNCOMMITTED 即可根治
查看答案与解析
正确答案B
正确原因： 死锁日志给出涉及语句、锁顺序与等待关系，据此调整访问顺序或拆分事务。
关键边界： 修改隔离级别不能根治写写冲突，重启会丢失现场。
错误选项辨析： 重启、删索引、改隔离级别都不是定位死锁的正确手段。
079 表级锁与行级锁的核心区别是？
难度： 基础
- A. 行锁一定比表锁慢
- B. 表锁只能用于 SELECT，不能用于写
- C. 表锁粒度大、并发低但开销小；行锁粒度细、并发高但管理复杂
- D. 行锁在锁冲突时不等待，直接报错
查看答案与解析
正确答案C
正确原因： 锁粒度是并发能力与管理开销的权衡，InnoDB 行锁粒度更细。
关键边界： 行锁基于索引实现，没有可用索引时可能锁住更多记录。
错误选项辨析： 行锁并发更高，表锁也用于写，行锁冲突会等待而非立即报错。
080 InnoDB 行锁“基于索引”的含义是？
难度： 进阶
- A. 只有主键才能被加锁
- B. 二级索引从不参与加锁
- C. 行锁与索引完全无关，锁的是内存对象
- D. 行锁实际加在索引记录上，没有可用索引时可能锁住更多行
查看答案与解析
正确答案D
正确原因： 锁加在索引记录上，执行计划扫描到的索引范围都会被锁定。
关键边界： 无索引条件时扫描范围扩大，锁定的行数可能远超目标行。
错误选项辨析： 二级索引同样参与加锁，行锁与索引定位强相关。