1）使用 mvcc 的方法，实现多事务的并发读写，但是这种读只是“快照读”，一般读的是历史版本数据，还有一种是“当前读”，一般加锁实现“当前读”，或者 insert、update、delete 也是当前读。
2）使用加锁的方法，锁分为共享锁（读锁），排他锁（写锁）
快照读：就是select
当前读：特殊的读 *** 作，插入/更新/删除 *** 作，属于当前读，处理的都是当前的数据，需要加锁。
mysql 在 RR 级别怎么处理幻读的呢？一般来说，RR 级别通过 mvcc 机制，保证读到低于后面事务的数据。但是 select for update 不会触发 mvcc，它是当前读。如果后面事务插入数据并提交，那么在 RR 级别就会读到插入的数据。所以，mysql 使用 行锁 + gap 锁（简称 next-key 锁）来防止当前读的时候插入。
Gap Lock在InnoDB的唯一作用就是防止其他事务的插入 *** 作，以此防止幻读的发生。
Innodb自动使用间隙锁的条件：
事务可以看见其他未提交事务的修改。会导致脏读。
事务只能看见其他提交事务的修改。但是如果事务A读取一批数据set，其他事务之后修改了这个数据set并提交(此时事务A没有提交)，这时事务A再读取数据set就跟第一次读取的结果不一致。会导致不可重复读。
在事务执行过程中，重复读到的数据是一致的
事务A读到了事务B未提交的数据。(read uncommitted)
事务A第一次读取行num，此时事务B修改行num并提交，事务A再读行num，数据会发生变化。（read uncommitted, read committed）
事务A第一次查询范围query_range，返回n行，此时事务B在该查询范围内插入了一行数据并提交，事务A再次查询范围query_range会看到B插入的数据。（read uncommitted, read committed, repeatable read）
在同一个事务执行过程中，两次相同的查询，但是查询的返回数据行数不同。
开启sessionA, sessionB
此时锁(行锁、gap锁)的情况如下图,标红为加锁，采用next key lock。(不光在索引a上加锁，索引a中3所对应的主键索引也会加锁，只画了索引a)
注意：这里是主键索引的顺序与a索引的顺序一致的情况。一致的情况下，新插入的4会插入在原来的4之后。我们定义函数index_key(x), 表示获取x所对应的主键索引，new(x)表示新插入的x，old(x)表示已经存在的x。如果index_key(old(4))>index_key(new(4))，那新的4是插不进去的，因为新的4会被放在老的4的前面。同理，新插入的2也有可能插入进去(只要index_key(new(2))<index_key(old(2)))。具体的例子整理后发出
对于sessionB，插入2，3失败，插入4成功。(如图lock.png，新插入的2会被2与3之间gap锁阻止，新插入的3肯定失败，但是新插入的4就没问题)
开启sessionA：
这个时候情况如下图所示:
如果按照实例1的分析，不看主键索引id，应该插入(id=4,a=3)应该会被gap锁锁定，但是事实是可以插入成功。因为插入的(i4=d,a=3)放在了(id=5,a=3)的上面。
同样的道理，不看主键索引id，通过实例1的分析，插入(id=6,a=7)应该可以插入，但是事实不行，因为(id=6,a=7)被a=5与a=7之间的gap锁阻止了。
新插入的(id=4, a=3)，需要判断会插入在(id=5, a=3)之前还是之后，很明显之前(4<5)，那么(id=3, a=5)与(id=5, a=3)之间的gap锁不会阻止。
新插入的(id=6, a=7)，需要判断会插入在(id=7, a=7)之前还是之后，很明显之前(6<7)，那么(id=6, a=7)会被(id=3, a=5)与(id=5, a=3)与(id=7, a=7)之间的gap锁阻止。
多线程开启事务处理。每个事务有多个update *** 作和一个insert *** 作（都在同一张表）。
默认隔离级别：Repeatable Read
只有hotel_id=2和hotel_id=11111的数据
逻辑删除原有数据
插入新的数据
根据现有数据情况，update的时候没有数据被更新
报了非常多一样的错
发现居然有死锁。
根据常识考虑，我每个线程（事务）更新的数据都不冲突，为什么会产生死锁？
带着这个问题，打印mysql最近一次的死锁信息
show engine innodb status
显示如下
发现事务1在等待一个锁
事务2也在等待一个锁
而且事物2持有了事物1需要的锁
关于锁的描述，出现了 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的执行过程：
因为普通索引
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
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）