mysql中一个RR模式下UPDATE锁范围扩大案例分析

本篇内容介绍了“mysql中一个RR模式下UPDATE锁范围扩大案例分析”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！这里只研究下锁的模式,借用叶老师的表和语句
我们先来看看下面两个语句的执行计划
下面两个语句的执行计划不一致，主要注意
type:index和range
key:PRIMARY和c2
我们先要清楚type:index和range的区别
这里借用我以前写的一篇文章
http://blog.itpub.net/7728585/viewspace-2139010/
type:index 不使用索引B+树结构,只使用索引叶子结点链表结构进行扫描，我们知道在索引的叶子结点有一个叶子结点开发云主机域名之间的双向指针，
并且叶子结点的数据是排序好的。他和ALL的方式类似，访问效率并不高，其主要的应用场景为用于避免order by使用using filesort
也就是避免排序。他是一种访问数据的方式，和range、const、ref、eq_ref等一样。
type:range 显然用于范围查询比如> between 等，其访问方式是考虑到索引的B+树结构的，需要通过根结点–>分支节点–>叶子结点的顺序访问
其实const、ref、eq_ref等一样也需要这样的定位过程。
我大概画一个图，示意图而已，但是足以解释我的意思
1.jpg
剩下我们需要考虑RR模式下，如下语句有哪些所结构：
我们这里先不考虑表级意向锁，只考虑这里打印出来的锁结构
行锁为：lock_mode X(LOCK_X)|LOCK_ORDINARY(next key lock)
同时我们注意到 0: len 8; hex 73757072656d756d; asc supremum
那么我们用一张图来表示
2.jpg
实际上我们从图中可以看出这种情况下RR模式下是主键上所有的行都加上了NEXT_KEY LOCK,所以你其他任何DML操作都会锁定
那么如下语句的锁结构呢？
如下：
我们可以清晰的观察到INDEX c2上包含
lock_mode X(LOCK_X)|LOCK_ORDINARY(next key lock)
其行包含了 C2:8/C1:6 C2:10/C2:10 还包含 supremum
同时传递到了主键PRIMARY锁结构为
lock_mode X(LOCK_X)|rec but not gap(LOCK_REC_NOT_GAP)
也就是主键上只是锁定了C1:6 C1:10这两行，并且不是gap lock，如果需要画图就是如下:
3.jpg
我们可以发现锁定的范围小了很多很多，这种情况如下语句：
select * from t1 where c1 = 7 for update;
(这里叶老师写的c2=7不知道是不是写错了)
是可以完成的，因为不会落到PRIMARY的锁定范围内。
这里只是看看RC模式的锁定结构如下：
我们可以清晰的看到RC模式下不考虑隐含锁的情况下只是锁定了PRIMARY的相应的行：
lock_mode X(LOCK_X) locks|rec but not gap(LOCK_REC_NOT_GAP)
注意这里NOT GAP“mysql中一个RR模式下UPDATE锁范围扩大案例分析”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注开发云网站，小编将为大家输出更多高质量的实用文章！

相关推荐: 【每日3分钟技术干货 | 面试题+答案 | Mysql篇(一

1. 数据库的三范式是什么？第一范式：强调的是列的原子性，即数据库表的每一列都是不可分割的原子数据项。第二范式：要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。2. 一张自增表里面总共有 7 条数据，删除了最后 2 条数据…