一次离奇的 MySQL 死锁分析
作者:李晶莹 发布时间:[ 2016/11/18 11:49:36 ] 推荐标签:数据库 MySQL 死锁
1、故事起因于2016年11月15日的一个生产bug。业务场景是:归档一个表里边的数据到历史表里边,同是删除主表记录。
2、背景场景简化如下(数据库引擎InnoDb,数据隔离级别RR[REPEATABLE])
-- 创建表test1
CREATE TABLE test1 (
id int(11) NOT NULL AUTO_INCREMENT,
name varchar(10) NOT NULL,
PRIMARY KEY (id)
);
insert into test1 values('hello');
-- 创建表test2
CREATE TABLE test2 (
id int(11) NOT NULL AUTO_INCREMENT,
name varchar(10) NOT NULL,
PRIMARY KEY (id)
);
-- Transcation 1
begin;
insert into test2 select * from test1 where id = 1;
delete from test1 where id = 1;
-- Transcation 2
begin;
insert into test2 select * from test1 where id = 1;
3、具体执行顺序
Mysql 官方解释
Deadlock occurs here because client A needs an X lock to delete the row. However, that lock request cannot be granted because client B already has a request for an X lock and is waiting for client A to release its S lock. Nor can the S lock held by A be upgraded to an X lock because of the prior request by B for an X lock. As a result, InnoDBgenerates an error for one of the clients and releases its locks. The client returns this error。
实际场景和mysql文档有些区别,文档里边要获取的是X锁。具体事例里边要获取的是S锁。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11