记一次线上问题引发的对 Mysql 锁机制分析 | 京东物流技术团队

背景

最近双十一开门红期间组内出现了一次因 Mysql 死锁导致的线上问题，当时从监控可以看到数据库活跃连接数飙升，导致应用层数据库连接池被打满，后续所有请求都因获取不到连接而失败

整体业务代码精简逻辑如下：

@Transaction
public void service(Integer id) {
    delete(id);
    insert(id);
}

数据库实例监控：

当时通过分析上游问题流量限流解决后，后续找时间又重新分析了下问题发生的根本原因，现将其总结如下：本篇文章会先对 Mysql 中的各种锁进行分析，包括互斥锁、间隙锁和插入意向锁，让大家对各种锁的使用场景有一个了解，然后在此基础上再对本问题进行分析，希望大家未来再碰到相似场景时，能够快速的定位问题

Mysql 锁机制

在 Mysql 中为了解决对同一行记录并发写的问题，引入了行锁机制，多个事务不能同时对一行数据进行修改操作，当需要对数据库中的一行数据进行修改时，会首先判断该行数据是否加锁，如果没加锁，那么当前事务加锁成功，可以进行后续的修改操作；但如果该行数据已经被其他事务加锁，则当前事务只有等待加锁的事务释放锁后才能加锁成功，继续执行修改操作

本篇文章中所有实验用到的建表语句：

create table `test` (
    `id` int(11) NOT NULL,
    `num` int(11) NOT NULL,
    PRIMARY KEY (`id`),
    KEY `num` (`num`)
) ENGINE = InnoDB;

insert into
    test
values
(10, 10),
(20, 20),
(30, 30),
(40, 40),
(50, 50);

Shared and Exclusive Locks

shared(S) lock 表示共享锁，当一个事务持有某行上的 S 锁后可以对该行的数据进行读操作，通过语句 select … from test lock in share mode 可以添加共享锁，**一般使用的较少，**不做过多阐述

exclusive(X) lock 表示互斥锁，当一个事务对某行数据进行 update 或 delete 操作时都要先获取到该记录上的 X 锁，如果已经有其他事务获取到了该记录上的 X 锁，那么当前事务会阻塞等待直到上一事务释放了对应记录上的 X 锁

S 锁之间不互斥，多个事务可以同时获取一条记录上的 S 锁 X 锁之间互斥，多个事务不能同时获取同一条记录上的 X 锁 S 锁和 X 锁之间互斥，多个事务不能同时获取同一条记录上的 S 锁和 X 锁

当多个事务同时去 update 索引上同一条记录时，都需要先获取到该记录上的 X 锁，所谓的锁也就是会在内存中生成一个数据结构来记录当前的事务信息、锁类型和是否等待等信息。下图中就是 T1 和 T2 同时去更新 id = 30 的这行记录，并且 T1 成功获取到了锁，其在内存中生成的锁结构信息中字段 is_wating 为 false，可以继续执行事务的后续逻辑，而 T2 获取锁失败，则生成的锁结构信息字段 is_wating 为 true，阻塞等待 T1 上的锁释放

互斥锁在 Mysql 日志中的锁信息为：lock_mode X locks rec but not gap

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t`
trx id 10078 lock_mode