锁是数据库并发控制的核心机制，也是面试中绕不开的高频考点。很多开发者对锁的理解停留在"加锁就行了"，但遇到死锁、锁等待超时、性能骤降等问题时往往束手无策。
本文将系统讲解数据库锁的分类、实现原理、锁与事务隔离级别的关系，并结合 MySQL InnoDB 深入分析锁的底层机制，最后给出死锁排查与优化实战。
一、为什么需要锁？
数据库需要同时处理多个并发请求，如果没有锁机制，就会出现：
-
丢失更新：两个事务同时读取同一数据并修改，后提交的覆盖先提交的
-
脏读：读到未提交的数据
-
不可重复读：同一事务内多次读取结果不一致
锁的本质：协调多个事务对共享资源的并发访问，保证数据的一致性和完整性。
二、锁的分类（从不同维度）
1. 按粒度分类
| 锁粒度 | 描述 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 表级锁 | 锁定整张表 | 开销小，加锁快，不会死锁 | 并发度低 | MyISAM、内存表、DDL操作 |
| 行级锁 | 锁定索引记录 | 并发度高，锁冲突概率低 | 开销大，加锁慢，可能死锁 | InnoDB 在线事务处理 |
| 页级锁 | 锁定数据页（8KB-16KB） | 介于表和行之间 | BDB 引擎使用，现已少见 | 历史遗留 |
2. 按模式分类
| 锁模式 | 英文 | 兼容性 | 说明 |
|---|---|---|---|
| 共享锁 | Shared Lock（S锁） | S 与 S 兼容，S 与 X 互斥 | 读锁，允许其他事务读取，禁止写入 |
| 排他锁 | Exclusive Lock（X锁） | X 与任何锁互斥 | 写锁，禁止其他事务读写 |
加锁语句示例：
sql
-- 共享锁（读锁）
SELECT * FROM user WHERE id = 1 LOCK IN SHARE MODE;
-- 排他锁（写锁）
SELECT * FROM user WHERE id = 1 FOR UPDATE;
UPDATE user SET name = 'new' WHERE id = 1; -- 自动加排他锁
DELETE FROM user WHERE id = 1; -- 自动加排他锁
INSERT INTO user VALUES (...); -- 自动加排他锁3. 按意向分类
意向锁（Intention Lock）是表级锁，表示事务想要在表中的某些行上加更细粒度的锁。
| 意向锁类型 | 含义 | 加锁时机 |
|---|---|---|
| 意向共享锁（IS） | 事务想要获得某些行的共享锁 | SELECT ... LOCK IN SHARE MODE |
| 意向排他锁（IX） | 事务想要获得某些行的排他锁 | SELECT ... FOR UPDATE、UPDATE、DELETE |
为什么需要意向锁？
如果没有意向锁，事务A要加表锁时，需要逐行检查是否有行锁，效率极低。意向锁的存在，让表锁可以快速判断是否有行锁冲突。
4. 按算法分类（InnoDB 行锁的三种实现）
| 锁算法 | 描述 | 锁定范围 | 防止幻读 |
|---|---|---|---|
| 记录锁 | 锁定单个索引记录 | 只锁定匹配的行 | 否 |
| 间隙锁 | 锁定记录之间的间隙 | 锁定范围，不包括记录本身 | 是 |
| 临键锁 | 记录锁 + 间隙锁 | 锁定记录及其前面的间隙（左开右闭） | 是 |
图示理解：
数据：id = 1, 2, 5, 8, 10
临键锁区间：(负无穷,1], (1,2], (2,5], (5,8], (8,10], (10,正无穷)
-- 执行以下语句（可重复读级别）
SELECT * FROM t WHERE id = 5 FOR UPDATE;
-- 锁定区间 (2,5] 和 (5,8]三、InnoDB 锁的底层实现
1. 锁的存储结构
InnoDB 的锁信息存储在锁管理器 （Lock Manager）中，每个锁对应一个 lock_t 结构体，包含：
-
锁类型（S/X）
-
锁模式（记录锁/间隙锁/临键锁）
-
锁定的行（通过 heap_no 标识）
-
持有锁的事务ID
2. 加锁流程
事务执行 SQL
↓
解析 SQL，确定需要锁定的行
↓
根据隔离级别和索引类型，确定锁算法
↓
在锁管理器中创建锁结构，尝试获取锁
↓
冲突？
├── 无冲突 → 获取锁成功，继续执行
└── 有冲突 → 等待，进入锁等待队列（可能死锁检测）3. 不同 SQL 的加锁行为
| SQL 语句 | 索引情况 | 加锁行为 |
|---|---|---|
SELECT ... FOR UPDATE |
使用主键/唯一索引 | 记录锁 |
SELECT ... FOR UPDATE |
使用普通索引 | 临键锁 + 回表记录锁 |
SELECT ... FOR UPDATE |
全表扫描 | 全表所有行的临键锁 |
UPDATE ... WHERE id = ? |
使用唯一索引 | 记录锁 |
UPDATE ... WHERE age > ? |
使用普通索引 | 临键锁 |
INSERT |
- | 排他锁 + 插入意向锁 |
DELETE |
- | 排他锁（根据条件加临键锁） |
4. 插入意向锁
插入意向锁是一种特殊的间隙锁，用于提高插入并发性能。
-
事务A在
(5,10)区间加了间隙锁 -
事务B要插入
id=7时，会在(5,10)上加插入意向锁 -
插入意向锁之间不互斥，多个事务可以同时插入不同位置
四、锁与事务隔离级别的关系
| 隔离级别 | 读取方式 | 加锁行为 | 锁释放时机 |
|---|---|---|---|
| READ UNCOMMITTED | 不加锁，直接读最新数据 | 几乎不加锁 | - |
| READ COMMITTED | 每次读取快照，不加锁 | 只加记录锁，不加间隙锁 | 语句执行完立即释放 |
| REPEATABLE READ | 第一次读取快照 | 临键锁（防止幻读） | 事务提交时释放 |
| SERIALIZABLE | 所有读都加共享锁 | 临键锁 + 共享锁 | 事务提交时释放 |
关键点：
-
RC 级别：只有记录锁，没有间隙锁，存在幻读风险
-
RR 级别 ：有临键锁，解决幻读（但
SELECT ... FOR UPDATE仍需注意） -
锁的释放时机：RC 级别语句结束释放，RR 级别事务结束释放（这是锁等待问题的根源）
五、死锁：数据库的"交通堵塞"
1. 什么是死锁？
两个或多个事务互相持有对方需要的锁，形成循环等待，谁都无法继续执行。
经典死锁示例：
sql
-- 事务A
BEGIN;
UPDATE account SET balance = balance - 100 WHERE id = 1;
UPDATE account SET balance = balance + 100 WHERE id = 2;
COMMIT;
-- 事务B
BEGIN;
UPDATE account SET balance = balance - 50 WHERE id = 2;
UPDATE account SET balance = balance + 50 WHERE id = 1;
COMMIT;
-- 并发执行顺序：
-- T1: A 锁定 id=1
-- T2: B 锁定 id=2
-- T3: A 等待 id=2 锁（B持有）
-- T4: B 等待 id=1 锁（A持有）
-- 死锁形成！2. 死锁的四个必要条件
-
互斥：资源只能被一个事务持有
-
持有并等待：事务持有锁的同时等待其他锁
-
不可剥夺：已获得的锁不能被强制释放
-
循环等待：形成等待环路
3. MySQL 死锁处理机制
-
死锁检测 ：InnoDB 通过等待图（Wait-for Graph）检测死锁，时间复杂度 O(n²)
-
回滚策略 ：选择回滚权重较小的事务（执行时间短、undo log 少的事务）
-
控制参数 ：
innodb_deadlock_detect（默认 ON，高并发下可关闭，用lock_wait_timeout替代）
4. 死锁排查与解决
查看最近一次死锁信息：
sql
SHOW ENGINE INNODB STATUS\G
-- 查看 LATEST DETECTED DEADLOCK 部分查看当前锁等待：
sql
-- 查看当前正在等待锁的事务
SELECT * FROM information_schema.INNODB_LOCK_WAITS;
-- 查看当前持有的锁
SELECT * FROM information_schema.INNODB_LOCKS;
-- 更直观的查询（MySQL 8.0）
SELECT * FROM performance_schema.data_locks;死锁优化策略：
| 策略 | 说明 |
|---|---|
| 固定访问顺序 | 所有事务按相同顺序访问资源（如先更新 id=1，再更新 id=2） |
| 缩小事务粒度 | 减少事务持有锁的时间，降低冲突概率 |
| 合理使用索引 | 避免全表扫描导致的锁范围过大 |
| 降低隔离级别 | RC 级别锁范围更小，死锁概率低于 RR |
使用 NOWAIT |
MySQL 8.0 支持 SELECT ... FOR UPDATE NOWAIT，不等待直接报错 |
六、锁监控与调优
1. 查看锁状态变量
sql
-- 查看 InnoDB 锁相关的状态
SHOW STATUS LIKE 'innodb_row_lock%';
-- 输出示例：
-- Innodb_row_lock_current_waits: 0 -- 当前等待锁的事务数
-- Innodb_row_lock_time: 123456 -- 总等待时间（ms）
-- Innodb_row_lock_time_avg: 100 -- 平均等待时间
-- Innodb_row_lock_time_max: 5000 -- 最大等待时间
-- Innodb_row_lock_waits: 123 -- 总等待次数2. 分析慢查询中的锁等待
sql
-- 开启慢查询日志，记录锁等待超过 2 秒的 SQL
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 2;
SET GLOBAL log_queries_not_using_indexes = ON;3. 优化建议
-
索引是锁的基础：无索引的 UPDATE/DELETE 会锁全表
-
避免大事务：事务越大，持有锁的时间越长，冲突概率越高
-
合理设计业务逻辑：将非核心操作移出事务
-
使用乐观锁：读多写少场景，用版本号代替悲观锁
七、乐观锁 vs 悲观锁
| 对比维度 | 乐观锁 | 悲观锁 |
|---|---|---|
| 核心思想 | 假设冲突很少发生，更新时检查版本 | 假设一定会冲突，提前加锁 |
| 实现方式 | 版本号、时间戳、CAS | 数据库行锁、SELECT FOR UPDATE |
| 适用场景 | 读多写少，冲突概率低 | 写多读少，冲突概率高 |
| 性能 | 无锁等待，吞吐量高 | 锁等待，吞吐量较低 |
| 重试机制 | 需要业务层重试 | 数据库自动等待 |
乐观锁示例：
sql
-- 表结构增加 version 字段
ALTER TABLE product ADD COLUMN version INT DEFAULT 0;
-- 查询时记录版本
SELECT id, stock, version FROM product WHERE id = 1;
-- 更新时检查版本
UPDATE product
SET stock = stock - 1, version = version + 1
WHERE id = 1 AND version = #{oldVersion};
-- 影响行数为 0 则重试八、总结与对比表
| 维度 | 要点 |
|---|---|
| 锁粒度 | 表锁 > 页锁 > 行锁（粒度越小，并发越高） |
| 锁模式 | 共享锁（读）、排他锁（写） |
| 锁算法 | 记录锁、间隙锁、临键锁（RR 级别默认） |
| 死锁四要素 | 互斥、持有并等待、不可剥夺、循环等待 |
| 排查工具 | SHOW ENGINE INNODB STATUS、performance_schema.data_locks |
| 优化方向 | 索引优化、缩小事务、固定顺序、降低隔离级别 |
一句话总结：锁是数据库并发控制的基石，理解锁的粒度、模式和算法，才能写出高性能、无死锁的数据库代码。