MySQL InnoDB行锁与间隙锁机制及死锁排查实战

InnoDB锁体系与隔离级别关系

MySQL InnoDB存储引擎的锁机制是数据库高可用架构中理解并发控制的基础。InnoDB支持行级锁，与MyISAM的表级锁相比，能大幅提升并发性能。但InnoDB的锁体系远不止”行锁”这么简单——在RR（Repeatable Read）隔离级别下，InnoDB通过间隙锁（Gap Lock）和Next-Key Lock解决幻读问题，这也使得锁冲突和死锁的概率增加。

InnoDB锁的完整分类包括：共享锁（S Lock）、排他锁（X Lock）、意向共享锁（IS Lock）、意向排他锁（IX Lock）、记录锁（Record Lock）、间隙锁（Gap Lock）、Next-Key Lock和插入意向锁（Insert Intention Lock）。这些锁的组合取决于隔离级别、索引类型和查询条件。

记录锁、间隙锁与Next-Key Lock工作机制

记录锁锁定索引记录本身。当使用唯一索引等值查询且记录存在时，InnoDB退化为记录锁，只锁定这一行：

-- 创建测试表
CREATE TABLE orders (
    id BIGINT PRIMARY KEY,
    order_no VARCHAR(32) NOT NULL,
    user_id BIGINT NOT NULL,
    amount DECIMAL(10,2),
    status VARCHAR(20) DEFAULT 'pending',
    INDEX idx_user_id (user_id),
    INDEX idx_status (status)
) ENGINE=InnoDB;

-- 插入测试数据
INSERT INTO orders (id, order_no, user_id, amount, status) VALUES
(10, 'ORD001', 100, 99.00, 'pending'),
(20, 'ORD002', 200, 199.00, 'paid'),
(30, 'ORD003', 300, 299.00, 'pending'),
(50, 'ORD004', 400, 399.00, 'paid');

-- Session 1: 通过主键等值查询加锁
START TRANSACTION;
SELECT * FROM orders WHERE id = 20 FOR UPDATE;
-- 此时只锁定id=20这一行（记录锁）

-- Session 2: 可以正常操作其他行
START TRANSACTION;
SELECT * FROM orders WHERE id = 30 FOR UPDATE; -- 成功，不阻塞
-- 但无法操作id=20
SELECT * FROM orders WHERE id = 20 FOR UPDATE; -- 阻塞

间隙锁锁定索引记录之间的间隙，防止其他事务在该间隙中插入新记录。在RR隔离级别下，当使用非唯一索引或范围查询时，InnoDB会加间隙锁：

-- Session 1: 通过非唯一索引等值查询，且记录存在
START TRANSACTION;
SELECT * FROM orders WHERE status = 'pending' FOR UPDATE;
-- 锁定status索引上 'pending' 对应的记录及间隙
-- 实际锁范围: (-∞, 'paid') 和 ('paid', +∞) 的Next-Key Lock
-- 即status='pending'的记录被Record Lock锁定
-- status='pending'与'paid'之间的间隙被Gap Lock锁定

-- Session 2: 尝试在间隙中插入
START TRANSACTION;
INSERT INTO orders (id, order_no, user_id, amount, status) 
VALUES (25, 'ORD005', 250, 149.00, 'processing');
-- 如果status='processing'落在被锁的间隙内，插入会阻塞

Next-Key Lock是记录锁与间隙锁的组合，锁定一个左开右闭区间。对于非唯一索引，InnoDB默认使用Next-Key Lock。例如在上述orders表中，idx_status索引上的记录为’pending’、’paid’，Next-Key Lock的锁范围为(-∞, ‘pending’]、(‘pending’, ‘paid’]、(‘paid’, +∞)。这意味着任何在’pending’和’paid’之间插入新status值的操作都会被阻塞。

死锁场景复现与排查方法

死锁发生在两个或多个事务互相持有对方需要的锁时。InnoDB有自动死锁检测机制，检测到死锁后会回滚成本较小的事务。以下是一个典型的死锁场景：

-- Session 1
START TRANSACTION;
UPDATE orders SET status = 'paid' WHERE id = 10;  -- 获取id=10的X锁

-- Session 2
START TRANSACTION;
UPDATE orders SET status = 'paid' WHERE id = 20;  -- 获取id=20的X锁

-- Session 1（继续）
UPDATE orders SET status = 'paid' WHERE id = 20;  -- 等待id=20的X锁，阻塞

-- Session 2（继续）
UPDATE orders SET status = 'paid' WHERE id = 10;  -- 等待id=10的X锁，阻塞
-- InnoDB检测到死锁，回滚Session 2
-- ERROR 1213 (40001): Deadlock found when trying to get lock;
-- try restarting transaction

排查死锁的标准方法是查看SHOW ENGINE INNODB STATUS输出的LATEST DETECTED DEADLOCK部分：

SHOW ENGINE INNODB STATUS\G

-- 输出中的死锁信息示例:
========================
LATEST DETECTED DEADLOCK
========================
2026-08-17 10:30:00 0x7f8b2c0a7000
*** (1) TRANSACTION:
TRANSACTION 123456, ACTIVE 3 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 10, OS thread handle 1402345678, query id 100 updating
UPDATE orders SET status = 'paid' WHERE id = 20

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 50 page no 3 n bits 72 index PRIMARY of table `test`.`orders`
trx id 123456 lock_mode X locks rec but not gap waiting

*** (2) TRANSACTION:
TRANSACTION 123457, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 11, OS thread handle 1402345679, query id 101 updating
UPDATE orders SET status = 'paid' WHERE id = 10

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 50 page no 3 n bits 72 index PRIMARY of table `test`.`orders`
trx id 123457 lock_mode X locks rec but not gap

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 50 page no 3 n bits 72 index PRIMARY of table `test`.`orders`
trx id 123457 lock_mode X locks rec but not gap waiting

*** WE ROLL BACK TRANSACTION (2)

这段输出清晰地展示了死锁的双方：事务1持有id=10的锁等待id=20的锁，事务2持有id=20的锁等待id=10的锁。lock_mode X locks rec but not gap表示这是记录锁（非间隙锁）。通过分析这些信息可以定位到具体的SQL语句和锁冲突点。

间隙锁导致的死锁与预防策略

间隙锁导致的死锁更隐蔽，因为事务可能因为插入到同一间隙而互相阻塞。典型场景如下：

-- 假设orders表中user_id索引有记录: 100, 200, 300
-- 间隙: (100, 200), (200, 300), (300, +∞)

-- Session 1: 查询user_id > 250的记录加锁
START TRANSACTION;
SELECT * FROM orders WHERE user_id > 250 FOR UPDATE;
-- 加Next-Key Lock: (200, 300], (300, +∞)

-- Session 2: 查询user_id < 250的记录加锁  
START TRANSACTION;
SELECT * FROM orders WHERE user_id < 250 FOR UPDATE;
-- 加Next-Key Lock: (-∞, 100], (100, 200], (200, 300]

-- Session 1: 尝试插入user_id=150的记录
INSERT INTO orders (id, order_no, user_id, amount) 
VALUES (15, 'ORD006', 150, 49.00);
-- 阻塞：user_id=150落在间隙(100, 200)内，被Session 2的间隙锁阻止

-- Session 2: 尝试插入user_id=350的记录
INSERT INTO orders (id, order_no, user_id, amount)
VALUES (35, 'ORD007', 350, 449.00);
-- 阻塞：user_id=350落在间隙(300, +∞)内，被Session 1的间隙锁阻止
-- 死锁发生

预防死锁的策略包括：统一加锁顺序，按主键或索引顺序操作数据；缩小事务范围，减少锁持有时间；使用RC隔离级别避免间隙锁（但需接受幻读风险）；使用INSERT ... ON DUPLICATE KEY UPDATE替代先查后插的写法；批量操作时按主键排序后再执行。

-- 预防策略示例：批量更新按主键排序
START TRANSACTION;
-- 先排序获取需要更新的ID列表
SELECT id FROM orders WHERE status = 'pending' ORDER BY id FOR UPDATE;
-- 然后按排序后的顺序逐一更新，确保所有事务按相同顺序加锁
UPDATE orders SET status = 'paid' WHERE id IN (10, 20, 30, 50) ORDER BY id;
COMMIT;

开启innodb_deadlock_detect参数（默认开启）确保死锁自动检测生效。对于高并发写入场景，适当调低innodb_lock_wait_timeout（默认50秒）可以让锁等待更快超时返回，减少用户等待时间。死锁无法完全避免，但通过合理的加锁顺序和事务设计，可以将死锁频率控制在可接受范围内。