带你读《2022技术人的百宝黑皮书》——mysql锁机制的再研究（2）

带你读《2022技术人的百宝黑皮书》——mysql锁机制的再研究（1）https://developer.aliyun.com/article/1340034?groupCode=taobaotech

行锁

InnoDB支持行级别锁， 锁粒度小并发度高，但是加锁开销大也很可能会出现死锁innodb行锁住的是索引项，注意当回表时，主键的聚簇索引也会加上锁。

举个栗子：

 INSERT INTO `test_lock` (`id`,`gmt_create`,`gmt_modified`,`lock_key`,`lock_context`,`lock_biz`) VALUES (1,now(),now(),'123456',null,'AccountUser');

当执行下面语句， 因为查询字段多余组合索引覆盖字段， 会出现回表操作补齐其他字段， 此时唯一索引lock_key=123423-lock_biz=AccountUsery以及主键索引 id=1，均被锁住。

1 select * from test_lock where lock_key='123456' and lock_biz='AccountUser' for update;

加锁方式：

1. 普通 select… 查询 (不加锁)
   
2. 普通 insert、update、delete… (隐式加写锁)
   
3. select…lock in share mode (加读锁)
   
4. select…for update (加写锁)
   

解锁：

提交/回滚事物（commit/rollback） kill 阻塞进程

由于行锁用的最多且更容易出现死锁问题，下面会详细讲述行锁。

锁的模式分类

我们常规理解的锁分为2大类：读锁（也叫共享锁，S）和写锁（也叫排他锁，X）。

这两把锁之间的兼容性说明如下表

横轴表示已持有的锁，纵轴表示尝试获取的锁。1表示成功（即兼容，表现为正常进行下一步操作），0表示失败

（即冲突，表现为阻塞住当前操作）

总结一句话就是：排他锁和任何锁均不兼容。

如果仅有读写锁，会存在一个性能问题，思考下面这个场景，其中T代表事务，T1代表事务1，以此类推。T1: 锁住表中的一行，只能读不能写（行级读锁）。

T2：申请整个表的写锁（表级写锁）。

如果T2申请成功，则能任意修改表中的一行，但这与T1持有的行锁是冲突的。故数据库应识别这种冲突，让T2的申请锁被阻塞，直到T1释放行锁。

若自己实现，最容易想到的识别方案就是遍历： step1：判断表是否已被其他事物用表锁锁住。step2: 判断表中的每一行是否已被行锁锁住。

其中step2需要遍历整个表，效率在数据库是没法接收的。因此innodb使用意向锁来解决这个问题

Innodb实现方案：                                                                                   T1需要先申请表的意向共享锁IS（注意意向共享锁为表级锁，且是由存储引擎自己维护，无需用户命手工命令干预），成功后再申请一行的行锁S。

在意向锁存在的情况下，上面的判断可以改为：step1:                            不变 step2:发现表上有意向共享锁，说明表中行被共享行锁锁住了，因此，事务B申请表的写锁被阻塞。

此时就引入的意向锁，加入意向锁后，锁的兼容性分析如下表：

横轴表示已持有的锁，纵轴表示尝试获取的锁。1表示成功（即兼容，表现为正常进行下一步操作），0表示失败

（即冲突，表现为阻塞住当前操作）

带你读《2022技术人的百宝黑皮书》——mysql锁机制的再研究（3）https://developer.aliyun.com/article/1340032?groupCode=taobaotech