锐客网

  1. 首页 > 睿知 > it技术 > >

mysql怎么处理死锁 mysql解决死锁的三种方法( 二 )

IT技术数据


关于锁的描述，出现了 lock_mode，gap before rec，insert intention 等字眼，看不懂说明了什么？说明我关于mysql的锁相关的知识储备还不够 。那就开始调查mysql的锁相关知识 。
通过搜索引擎，
锁的持有兼容程度如下表
那么再回到死锁日志，可以知道 :
事务1正在获取插入意向锁
事务2正在获取插入意向锁，持有排他gap锁
再看我们上面的锁兼容表格，可以知道，gap lock和insert intention lock是不兼容的
那么就可以推断出： 事务1持有gap lock，等待事务2的insert intention lock释放；事务2持有gap lock，等待事务1的insert intention lock释放，从而导致死锁 。
那么新的问题就来了，事务1的intention lock 为什么会和事务2的gap lock 有交集，或者说 ， 事务1要插入的数据的位置为什么会被事务2给锁?。?
让我回顾一下gap lock的定义：
间隙锁，锁定一个范围，但不包括记录本身 。GAP锁的目的，是为了防止同一事务的两次当前读，出现幻读的情况
那为什么是gap lock，gap lock到底是基于什么逻辑锁的记录？发现自己相关的知识储备还不够 。那就开始调查 。
调查后发现，当当前索引是一个 普通索引 的时候 ， 会加一个gap lock来防止幻读，此gap lock 会锁住一个左开右闭的区间 。假设索引为xx_idx（xx_id），数据分布为1,4,6,8,12 ， 当更新xx_id=9的时候，这个时候gap lock的锁定记录区间就是(8，12]，也就是锁住了xxid in (9,10,11,12)的数据 ， 当有其他事务要插入xxid in (9,10,11,12)的数据时，就会处于等待获取锁的状态 。
ps：当前索引不是普通索引，而且是唯一索引等其他情况 ， 请参考下面资料
MySQL 加锁处理分析
回到我自己的案例中，重新屡一下事务1的执行过程：
【mysql怎么处理死锁 mysql解决死锁的三种方法】 因为普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的关系 这段sql会获取一个gap lock，范围(2,11111]
这段sql会获取一个insert intention lock （waiting）
再看事务2的执行过程
因为普通索引
KEY hotel_date_idx ( hotel_id , rate_date )
的关系 这段sql也会获取一个gap lock，范围也是(2,11111]（根据前面的知识 ， gap lock之间会互相兼容，可以一起持有锁的）
这段sql也会获取一个insert intention lock （waiting）
看到这里，基本也就破案了 。因为普通索引的关系 ， 事务1和事务2的gap lock的覆盖范围太广，导致其他事务无法插入数据 。
重新梳理一下：
所以从结果来看 ， 一堆事务被回滚，只有10007数据被更新成功
gap lock 导致了并发处理的死锁
在mysql默认的事务隔离级别（repeatable read）下，无法避免这种情况 。只能把并发处理改成同步处理 。或者从业务层面做处理 。
共享锁、排他锁、意向共享、意向排他
record lock、gap lock、next key lock、insert intention lock
show engine innodb status
巧用MySQL InnoDB引擎锁机制解决死锁问题[2] 索引 KEY_TSKTASK_MONTIME (STATUS_ID MON_TIME)
分析 涉及的两条语句应该不会涉及相同的TSK_TASK记录 那为什么会造成死锁呢？
查询MySQL文档 发现这跟MySQL的索引机制有关 MySQL的InnoDB引擎是行级锁 我原来的理解是直接对记录进行锁定 实际上并不是这样的
要点如下:
不是对记录进行锁定 而是对索引进行锁定
在UPDATE DELETE操作时 MySQL不仅锁定WHERE条件扫描过的所有索引记录 而且会锁定相邻的键值 即所谓的next key locking
如语句UPDATE TSK_TASK SET UPDATE_TIME = NOW() WHERE ID会锁定所有主键大于等于 的所有记录 在该语句完成之前 你就不能对主键等于 的记录进行操作

推荐阅读


上一篇：远程连接sqlserver数据库服务器，远程连接sql server数据库

下一篇：直播网红营销，直播网红的营销策略