sql死锁分析

一、重要参数
获取事务信息:SELECT * FROM information_schema.INNODB_TRX;
获取锁等待:SELECT * FROM information_schema.INNODB_LOCK_WAITS;
查看锁信息:SELECT * FROM information_schema.INNODB_LOCKS WHERE lock_trx_id IN ()
二、case1:间隙锁和x锁互斥导致死锁
1、背景:
现将员工从一个组别中移除,同时将员工加入到另一个组别中,如果出现并发情况,就会出现交叉情况,导致死锁
2、死锁原因分析


3、解决办法:
1、由于一次操作只会是一个人,所以把员工的in查询改为==查询,事务a和事物b只会有一个拿到uid的锁,解决并发问题
2、将两个操作拆分,分成两个小事物,分别进行提交
三、case2 两条插入语句发生死锁(on duplicate key update)
1、背景:
首先insert on duplicate key 这条sql的语义是：如果insert中的对应键值在数据库中没有找到对应的唯一索引记录，即进行插入；如果对表中唯一索引记录冲突，便进行更新，能够很轻松的达到一种效果： 有则直接更新，无则插入。 首先，在RR的事务隔离级别下，insert on duplicate key这个sql与普通insert只插入意向锁和记录锁不同，insert on duplicate key sql如果没有找到对应的会在唯一键上插入gap lock和插入意向锁（如果有对应记录则会获取next key lock，next key lock 比gap lock多了一个边缘的记录锁）。
注意:向同一个普通索引插入数据,两个线程出现了并发,产生了互相依赖
2、死锁原因分析


本质原因:
1、INSERT … ON DUPLICATE KEY UPDATE时,会给每行加一个间隙锁和插入意向锁
2、当持有间隙锁时候,再次申请意向插入锁时,获取不到锁

3、解决办法:
1、改为使用普通的insert插入,当出现重复时,手动捕获异常进行更新逻辑

四、两个普通批量插入导致死锁
一、背景
批量添加黑猫数据抓取执行结果保存,但是两个事物保存的顺序存在交叉情况,交叉内容完全一致,出现abba情况
二、死锁原因分析


3、解决方案
1、减少批量保存任务,如果需要批量保存,需要保证保存内容的顺序一致性
2、调整索引或者业务逻辑

五、两个update操作导致死锁(常见)
1、事务a更新id=1记录,事务b更新id=2记录,事务a更新id=2记录事务b更新id=1记录,立刻发生死锁,同样是abba场景
2、死锁分析
– 事务A
BEGIN;
UPDATE my_table SET value=‘A’ WHERE id=1;
– 事务B（在事务A未提交前执行）
BEGIN;
UPDATE my_table SET value=‘B’ WHERE id=2;
– 事务A（继续尝试执行）
UPDATE my_table SET value=‘A1’ WHERE id=2; – 被阻塞
– 事务B（继续尝试执行）
UPDATE my_table SET value=‘B1’ WHERE id=1; – 死锁
3、如何解决
可以采用顺序锁机制、短事务、合适的隔离级别、优化SQL查询、应用层保障顺序执行等策略