1.执行顺序不一致导致
======trx1=======
select * from tb1 where id=1 for update
select * from tb1 where id=2 for update
======trx2=======
select * from tb1 where id=2 for update
select * from tb1 where id=1 for update
2. 非主键、唯一索引 隐式加锁
mysql 死锁信息dump出来sql 结构一致,比如
代码中的事务其实还执行了另外一条SQL语句,但是死锁信息未暴露出来
例如 tab 1 index 信息包含 primary key(id), index (name);表中 记录
id
name
1
john
2
john
#######
======trx1=======
select * from tb1 where id=1 for update
select * from tb1 where name ='john' for update
======trx2=======
select * from tb1 where id=2 for update
select * from tb1 where name ='john' for update
###########
select * from tb1 where name ='john' for update 此语句走普通索引,
加锁步骤:1. lock index(name) 2.lock 步骤1对应的primary 聚簇索引
所以 执行过程 为: trx1 id=1加锁X,语句2 尝试加id in(1,2);trx2 id=2加锁X,语句2 尝试加id in(1,2);加锁顺序不一致
3.类似2,非主键、唯一索引 隐式加锁,但不同点是trx1 和2 都各自执行一条sql ,走了不同的但是都是非聚簇索引
#############
参考文章内容举例如 tab 1 index 信息包含 primary key(id), index (name), index (sn);表中 记录
id
name
sn
1
john
100
2
john
10
======trx1=======
select * from tb1 where name ='john' for update
//加锁顺序为 1,2
======trx2=======
select * from tb1 where sn>10 for update
//加锁顺序为 2,1
###########
此类型疑问: 虽然文中所说 索引加锁顺序是因为B+树结构的有序性 ,这个有序性具体运行时,是如何决策的
###################### 其他 ##################################
GAP锁是为了解决幻读的问题; RC隔离级别,不会出现幻读 在RC级别下不存在GAP锁