mysql中的行锁
在分析死锁之前，我们先来回忆一下MySQL中的行锁。MySQL有如下三种类型的行锁，本节只简单介绍一下，想深入了解看我的其他文章
Record Lock：对单个记录加锁
Gap Lock：锁住记录前面的间隙，不允许插入记录
Next-key Lock：同时锁住数据和数据前面的间隙，即数据和数据前面的间隙都不允许插入记录
Insertion Intention Gap Lock（插入意向锁）
简单的insert会在insert的行对应的索引记录上加一个排它锁，这是一个record lock，并没有gap，所以并不会阻塞其他session在gap间隙里插入记录。
不过在insert操作之前，还会加一种锁，官方文档称它为insertion intention gap lock，也就是意向的gap锁。这个意向gap锁的作用就是预示着当多事务并发插入相同的gap空隙时，只要插入的记录不是gap间隙中的相同位置，则无需等待其他session就可完成，这样就使得insert操作无须加真正的gap lock。
如果使用 Gap Lock 的话，插入的并发性将比较低
如何排查死锁？
发生死锁的条件
- 互斥，共享资源X和Y只能被一个线程占用
- 占有且等待，线程T1已经取得共享资源X，在等待共享资源Y的时候，不释放共享资源X
- 不可抢占，其他线程不能强行抢占线程T1占用的资源
- 循环等待，线程T1等待线程T2占用的资源，线程T2等待线程T1占有的资源，就是循环等待
我们先造一个死锁的例子，给大家演示一下死锁的基本排查思路
CREATE TABLE `order_info` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '订单编号',
`status` tinyint(3) NOT NULL COMMENT '订单状态',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='订单表';
insert into order_info (id, status) values (1, 0), (2, 0);
| 时间 | 客户端A | 客户端B |
|---|---|---|
| T1 | begin; update order_info set status = 1 where id = 1; | |
| T2 | begin; update order_info set status = 2 where id = 2; | |
| T3 | update order_info set status = 1 where id = 2; | |
| T4 | update order_info set status = 2 where id = 1; 死锁回滚 | |
| T1 | commit； |
发生死锁时，mysql会选择一个开销最小的事务进行会滚，这样另一个事务就能正常执行
执行如下语句获取最近一次的死锁记录
show engine innodb status
从死锁日志我们可以分析出如下有用信息
事务1死锁时正在执行如下语句
update order_info set status = 1 where id = 2;
事务2死锁时正在执行如下语句
update order_info set status = 2 where id = 1;
并且事务1等待的锁正好是事务2获取的锁，并且肯定事务2等待的锁已经被事务1获取了。
此时我们就需要去看业务代码，是如何产生死锁的，只要破坏死锁产生的条件即可。
例如想避免这个例子中的死锁，我们只需要破坏循环等待的条件，按序更新资源即可（即更新多个资源时，都是按照id从小到大更新）
生产环境死锁了
聊一个我们之前生产环境遇到的死锁问题，以便加深大家的印象（当然实际情况没那么容易排查，因为一个事务中执行的sql比较多，所以能迅速找出问题还是比较考验功底的）
有如下2张表，插入一条账户记录
CREATE TABLE `balance_account` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '账户编号',
`member_code` varchar(50) NOT NULL COMMENT '用户编号',
`balance` bigint(20) NOT NULL COMMENT '账户余额',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='账户表';
CREATE TABLE `balance_charger` (
`id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '自增主键',
`member_code` varchar(50) NOT NULL COMMENT '用户编号',
`charger_num` varchar(50) NOT NULL COMMENT '流水单据号',
`status` tinyint(3) NOT NULL COMMENT '流水状态，0初始状态，1完成',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=15 DEFAULT CHARSET=latin1 COMMENT='账户流水表';
insert into balance_account(id, member_code, balance) value (1, 'a', 0);
当用户账户的钱发生变化的时候，我们需要按序操作这2张表
// 插入流水
insert balance_charger;
// 更新账户
update balance_account;
// 更新流水
update balance_charger;
| 时间 | 客户端A（Tab A） | 客户端B（Tab B） |
|---|---|---|
| T1 | begin; insert into balance_charger (member_code, charger_num, `status`) values (‘a’, ‘v1’, 0); update balance_account set balance = balance + 100 where id = 1; | |
| T2 | begin; insert into balance_charger (member_code, charger_num, `status`) values (‘a’, ‘v2’, 0); update balance_account set balance = balance + 100 where id = 1; | |
| T3 | update balance_charger set status = 1 where charger_num = ‘v1’; | |
| T4 | 死锁回滚 | |
| T5 | commit; |
那这个死锁是如何产生的呢？
当update语句的where条件没有使用索引时，就会全表扫描，对全表的记录加上Next-key Lock，相当于把整个表锁住了！
如何解决呢？
很简单，给where条件中的列加索引即可
ALTER TABLE balance_charger ADD INDEX idx_charger_num(`charger_num`)
参考博客
[1]https://mp.weixin.qq.com/s/B_slzAZLp-y8G0haZwIbTg
[2]https://bbs.huaweicloud.com/blogs/300169
插入意向锁
[3]https://www.cnblogs.com/better-farther-world2099/articles/14722850.html
[4]https://juejin.cn/post/6844903666856493064
还没有评论，来说两句吧...