从前面的实验中可以看到无论是INSERT还是REPLACE,在高并发的情况下由于唯一键的存在,即使在 RC 隔离级别下,仍然有较大概率会触发到死锁。当前只能在业务端做好容错处理,以下是一些小建议来减少或避免INSERT死锁: RC 隔离级别相较 RR 隔离级别产生死锁的概率小,但仍不可避免。 INSERT ... ON DUPLICATE KEY UPDATE...
当session1执行insert into tb select 15;,session1 已获取到IX锁,gap锁, 等待rec insert intention(插入意向锁), session1, session2 都在等待插入意向锁, 插入意向锁与gap锁冲突,双方都没有释放gap锁,又都在等待插入意向锁,死锁发生。 LATESTDETECTEDDEADLOCK --- 2018-11-03 17:15:110x7f4b0e7ea700 *...
即在update、delete语句后会产生间隙锁和Next-key lock,如果在并发下,存在两个事务都事前执行了UPDATE语句(各自持有了gap lock),当INSERT时,要先在插入间隙上获取插入意向锁,由于插入数据的间隙存在冲突,所以会互相等待获取插入意向锁,即相互竞争,最终会导致一方死锁。
所以似乎跟delete操作有关,InnoDB因为delete-marked记录引发的死锁或锁超时问题很多,看起来我们又遇到了一例。 其实关于这个问题,姜承尧老师的文章http://www.innomysql.com/26186-2/,该文对insert操作的并发性做了比较详细地解释。这里我直接给结论,感兴趣的同学可以看文中的分析过程。 在RC隔离级别下,要让insert操...
这里产生死锁的关键就是 GAP 锁。GAP 锁是在 RR 隔离级别下用于解决幻读问题,但是 RC 隔离级别下,在重复键检查和外键检查时也会用到。 再浅浅回顾一下INSERT语句加锁类型: 被GAP 锁阻塞时,生成一个插入意向锁。 遇到重复键冲突时 主键冲突,产生 S 型记录锁(RR 和 RR 隔离级别,实际上在 INSERT 阶段时还是...
MySQL死锁案例分：先delete，再insert，导致死锁⼀、死锁案例 MySQL版本：Percona MySQL Server 5.7.19 隔离级别：可重复读（RR）业务逻辑：并发下按某个索引字段先delete记录，再insert记录 ⽐如：1.begin;2.delete from tb where order_id = xxx;3.insert into tb(order_id) values(xxx);4.commit;⼆...
insert (3,3,5) 申请lock S 被sess2 delete 持有的Lock X 行锁阻塞, show engine innodb status 并没有完整的显示 该lock S 是什么锁。我们继续测试。 测试案例二 T1 sess1 mysql > delete from t where a=3 and b=3 ; mysql > insert into t(a,b,c) values(3,3,5); ...
加上共享锁后,对于update,insert,delete语句会自动加排它锁。 排它锁 exclusive lock,也叫writer lock,X锁,写锁。排它锁指对于多个不同的事务,对同一个资源只能有一把锁。若事务1对数据对象A加上X锁,事务1 可以读A也可以修改A,其他事务不能再对A加任何锁,直到事务1 释放A上的锁。这保证其他事务在事务1...
2. delete导致死锁问题 和前面操作基本一致,只是第一个会话是删除记录 step1: 代码语言:javascript 复制 --session1:begin;deletefrom t where id=1;--session2:begin;insert into tvalues(1);--阻塞--session3:begin;insert into tvalues(1);--阻塞 ...
INSERT / UPDATE / DELETE:加排他(X)锁 当前读在 RR 和 RC 两种隔离级别下的实现也是不一样的:RC 只加记录锁,RR 除了加记录锁,还会加间隙锁,用于解决幻读问题。 不同SQL 语句对加锁的影响 不同的 SQL 语句当然会加不同的锁,总结起来主要分为五种情况: ...