【MySQL】说透锁机制（二）行锁 加锁规则 之 范围查询（你知道会锁表吗？

于 2024-06-19 15:40:18 发布
阅读量845 收藏 14
点赞数 18
文章标签： mysql android 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/2401_85111662/article/details/139805112
版权

新打开一个mysql客户端，我们叫Session1，并开启锁监视器：

SET GLOBAL innodb_status_output=ON;
SET GLOBAL innodb_status_output_locks=ON;

说明，本文基于：MySQL5.7、InnoDB引擎、可重复读事务隔离级别

聚集索引

小于

新打开一个mysql客户端，我们叫Session2， 执行SQL如下（按id < 20）：

begin;
update ct set remark = '巴西 爆冷 克罗地亚' 
where id < 20;

注意不要commit或rollback，以便于我们分析行锁

这里匹配id < 20 的 记录有两条：
![在这里插入图片描述](https://img-blog.csdnimg.cn/bacea057d038408bbce106054cd8c5a2.png
然后我们在Session1里查看锁的详细信息

show engine innodb status\G;

我们还是主要看TRANSACTIONS这段，如下图：
在这里插入图片描述

这里上了 3 把锁，因为是 按id，所以全锁在 聚集索引 上：

  1. id = 20 （向右扫描到的第一个不匹配记录）: Next-key Lock；
  2. id = 10（匹配记录） : Next-key Lock；
  3. id = 15（匹配记录） : Next-key Lock；

因为 20 刚好是临界值。如果我们换成 id < 19呢？

update ct set remark = '巴西 爆冷 克罗地亚' 
where id < 19;

再来看一下：

show engine innodb status\G;

在这里插入图片描述
结果依旧！！！（你可以对比一下：上一个事务ID是：793365）：
还有一个临界值 id < 16 ：

update ct set remark = '巴西 爆冷 克罗地亚' 
where id < 16;

结果也是一样的，就不展示了。

所以对于 < 在 聚集索引 上来说，我们得出的结果是：

  • 聚集索引上, 所有匹配的 索引记录 上Next-key Lock;
  • 向右扫描聚集索引, 直到找到 [不匹配的索引记录] 上Next-key Lock.

小于等于

这里依旧演示两个临界值： id <=19 和 id <= 20

begin;
update ct set remark = '巴西 爆冷 克罗地亚' 
where id <= 19;

这里匹配记录有 id =10 和 id =15 两条记录。

我们来看一下：

show engine innodb status\G;

在这里插入图片描述
不出所料，因为 和 id < 19 的匹配记录是相同的，所以锁的结果也是相同的！
我们再来看一下临界值 id <=20：

begin;
update ct set remark = '巴西 爆冷 克罗地亚' 
where id <= 20;

我们看一下修改的记录，共3条：
在这里插入图片描述
这里对于 3条匹配的 索引记录，上Next-key Lock已尽在我们掌握中，但id = 30 是否会上锁？
如果上的话，是上 Next-key Lock 还是Gap Lock？

我们来看一下：

show engine innodb status\G;

在这里插入图片描述
可以看出上了4把锁：3条已匹配记录上了Next-key Lock，向右查找到不匹配的30也上了Next-key Lock。
其实这里不知道你会不会有这个 疑问 ：对于聚集索引来说，值是唯一的，既然已经匹配到最大的20了，中止是不是更好？为什么还要继续向右？
如果是<=21，因为21不存在，所以需要继续向右扫描直到查找到30，上一把Next-key Lock倒可以理解！

其实疑问早就存在，前腾讯云数据库负责人林晓斌还曾找社区专家讨论过，官方bug系统上也有提到，但是并未被verified，所以这个也被他称之为bug！

对于 <= 在 聚集索引 上来说，我们得出的结果是（实际和 < 一样）：

  • 聚集索引上, 所有匹配的 索引记录 上Next-key Lock;
  • 向右扫描聚集索引, 直到找到 [不匹配的索引记录] 上Next-key Lock.

大于

我们再来验证 id > 10：

update ct set remark = '巴西 爆冷 克罗地亚' 
where id > 10;

这时匹配的记录有 15、20、30、40，所以会上4把Next-key Lock，对于40后的间隙，是对supremum上了Next-key Lock，这个很好理解，没什么特殊的，请看下图：
在这里插入图片描述
对于 > 在 聚集索引 上来说，我们得出的结果是（实际和 <, <= 类似）：

  • 聚集索引上, 所有匹配的 索引记录 上Next-key Lock;
  • 对supremum (上界限伪值) 上Next-key Lock：锁的是最大值后的间隙;

大于等于

我们最后来看一下 id >= 10，这个有点特殊：

update ct set remark = '巴西 爆冷 克罗地亚' 
where id >= 10;

在这里插入图片描述

对于 >= 我们得到的结果是：

  • 聚集索引上, 所有 > 的 索引记录 上Next-key Lock;
  • 聚集索引上, 等值(=) 会上Record Lock，当然：如果没有 等值(=) 就不会上锁，我已验证 id>=11，比较好理解，不做赘述！
  • 对supremum (上界限伪值) 上Next-key Lock：锁的是最大值后的间隙;

范围组合

范围组合一： > <

update ct set remark = '匹配15' 
where id > 10 and id < 20;

在这里插入图片描述
由图可知，对2条索引记录上锁：匹配：15，next-key：20
结果：

  • 聚集索引上, 所有匹配的 索引记录 上Next-key Lock;
  • 向右扫描聚集索引, 直到找到 [不匹配的索引记录] 上Next-key Lock.

范围组合二： > <=

update ct set remark = '匹配15 + 20' 
where id > 10 and id <= 20;

在这里插入图片描述
由图可知，对3条索引记录上锁：匹配：15、20，next-key：30

结果 和> <相同，不做赘述！

范围组合三： >= <

update ct set remark = '匹配10 + 15' 
where id >= 10 and id < 20;

在这里插入图片描述
由图可知，对3条索引记录上锁：匹配：10、15，next-key：20
结果：

  • 只有 >= 的等值(=)匹配索引记录上Record Lock，其它匹配的 索引记录 上Next-key Lock;
  • 向右扫描 直到找到 不匹配 的 索引记录 上Next-key Lock.

范围组合四： >= <=

update ct set remark = '匹配10 + 15 + 20' 
where id >= 10 and id <= 20;

在这里插入图片描述
由图可知，对4条索引记录上锁：匹配：10、15、20，next-key：30
结果 和>= <相同，不做赘述！

聚集索引 小结

对于 聚集索引下的范围查询 <、<=、>、>=，无论是否组合，都会遵循如下规则：

  • 所有匹配的索引记录：只有>= 的等值(=)匹配 上Record Lock，其它 上Next-key Lock;
  • 对于 < 和 <=：向右扫描聚集索引，直到找到 不匹配 的 索引记录 上Next-key Lock.
  • 对于 > 和 >=，会对supremum (上界限伪值) 上Next-key Lock：锁的是 聚集索引 最大值 后面的 间隙;

唯一索引

小于

我们在Session2 执行SQL如下（按abc_uk < 20）：

update ct set remark = '巴西 爆冷 克罗地亚' 
where abc_uk < 20;

在这里插入图片描述
这里共匹配2条记录：abc_uk = 10 和 abc_uk = 15。

共上了 6 把锁，3把锁在唯一索引上：

  1. abc_uk = 20 （向右扫描到的第一个不匹配记录）: Next-key Lock；
  2. abc_uk = 10（匹配记录） : Next-key Lock；
  3. abc_uk = 15（匹配记录） : Next-key Lock；

3把锁在聚集索引上：

  1. id = 20 （向右扫描到的第一个不匹配记录）: Record Lock；
  2. id = 10（匹配记录） : Record Lock；
  3. id = 15（匹配记录） : Record Lock；

到这，我猜你肯定认为 和 聚集索引 一样有结果了，请看好了，好戏即将上演~
我改下sql，sql语句本身没变，只是 20换成30：

update ct set remark = '巴西 爆冷 克罗地亚' 
where abc_uk < 30;

这里共匹配3条记录，分别是abc_uk = 10 、15、20。
我们看一下锁监视器：
在这里插入图片描述
这里对聚集索引上了6把锁！！！
表里所有的5条聚集索引记录都上了Next-key Lock，还把supremum上了Next-key Lock。

你是不是会怀疑我搞错了？

那咱们走着瞧~，咱们先看一下explain的结果：
在这里插入图片描述
possible_keys： uk_abc_uk，意思说可能走的索引是uk_abc_uk
key：PRIMARY，意思说实际走的索引是聚集索引
type：index，意思说扫描了整个索引树

所以：这条SQL并没有使用唯一索引，而使用的是全表扫描。
这里其实是索引相关的知识，也就是索引失效了，实际是通过索引成本计算，得出全表扫描的cost(3.9) 小于 走唯一索引再回表的cost(4.61)：
在这里插入图片描述
全表扫描的成本计算（上图）：

  • I/0成本：1*1.0+1.1 = 2.1
  • CPU成本：4*0.2+1.0 = 1.8
  • 总成本：I/0成本(2.1)+CPU成本(1.8) = 3.9

在这里插入图片描述
使用唯一索引的成本计算（上图）：

  • I/0成本1 - 范围区间的数量: 1 * 1.0 = 1.0
  • I/0成本2 - 回表成本：3 * 1.0 = 3.0
  • CPU成本：3 * 0.2 + 0.01 = 0.61
  • 总成本：I/0成本(4.0)+CPU成本(0.61) = 4.61

说白了，就是表里一共才5条记录，这个范围就匹配了3条记录，我用唯一索引先查id，再用id回表去修改，还不如直接遍历全表来的快！！！
实际项目里，表里的数据一般不会这么少，所以这个示例的修改占比(60%)还是很高的，所以才造成了全表扫描(全表成本低于使用索引)。

对于索引要细说的话内容很多，远没有这么简单，这里只是简单说明，不懂不要紧，先作为了解，后面再安排细聊索引的成本计算！

安排结果！对于 < 在 唯一索引 上来说，我们得出的结果是：

  • 如果走了唯一索引：
    • 在该索引上，所有匹配的索引记录 上Next-key Lock，对应的聚集索引 上Record Lock;
    • 向右扫描该索引，直到找到 [不匹配的索引记录] 上Next-key Lock，对应的聚集索引 上Record Lock;
  • 如果没走唯一索引，那么就会把所有 聚集索引记录 和 间隙 都锁上，就是所谓的锁表，或叫行锁升表锁.

小于等于

update ct set remark = '巴西 爆冷 克罗地亚' 
where abc_uk <= 19;

在这里插入图片描述
不出所料，因为 和 abc_uk < 20 的匹配记录是相同的，所以锁的结果也是相同的！

我们再来看一下临界值 abc_uk <=20：

begin;
update ct set remark = '巴西 爆冷 克罗地亚' 
where abc_uk <= 20;

这里依然是会影响到3条记录 abc_uk = 10、15、20，所以你懂的，又锁表了！！！ 具体就不截图了。

所以我们改成范围小一点的临界值 abc_uk <=15：

begin;
update ct set remark = '巴西 爆冷 克罗地亚' 
where abc_uk <= 15;

这里只会影响到2条记录 abc_uk = 10、15

我们来看一下：

show engine innodb status\G;

在这里插入图片描述
这里共匹配2条记录：abc_uk = 10 和 abc_uk = 15。

共上了 6 把锁，3把锁在唯一索引上：

  1. abc_uk = 20 （向右扫描到的第一个不匹配记录）: Next-key Lock；
  2. abc_uk = 10（匹配记录） : Next-key Lock；
  3. abc_uk = 15（匹配记录） : Next-key Lock；

3把锁在聚集索引上：

  1. id = 20 （向右扫描到的第一个不匹配记录）: Record Lock；
  2. id = 10（匹配记录） : Record Lock；
  3. id = 15（匹配记录） : Record Lock；

综上，对于 <= 在 聚集索引 上来说，我们得出的结果 实际和 < 一样，不做赘述！

大于

我们先来验证 abc_uk > 10：

update ct set remark = '阿根廷 3:0 克罗地亚' 
where abc_uk > 10;

这里共匹配4条记录：abc_uk = 15、20、30、40，所以你懂的，又锁表了！！！ 具体就不截图了。

所以我们改成范围小一点的 abc_uk > 20：

update ct set remark = '阿根廷 3:0 克罗地亚' 
where abc_uk > 20;

这里只会影响到2条记录 abc_uk = 30、40

我们来看一下：

show engine innodb status\G;

在这里插入图片描述
这里共匹配2条记录：abc_uk = 30 和 abc_uk = 40。

共上了 5把锁，3把锁在唯一索引上：

  1. abc_uk = supremum （上界限伪值，锁的是最大值后的间隙）: Next-key Lock；
  2. abc_uk = 30（匹配记录） : Next-key Lock；
  3. abc_uk = 40（匹配记录） : Next-key Lock；

2把锁在聚集索引上：

  1. id = 30（匹配记录） : Record Lock；
  2. id = 40（匹配记录） : Record Lock；

对于 > 在 唯一索引 上来说，我们得出的结果是（实际和 <, <= 类似）：

  • 如果走了唯一索引：
    • 在该索引上，所有匹配的索引记录 上Next-key Lock，对应的聚集索引 上Record Lock;
    • 在该索引上，对supremum (上界限伪值) 上Next-key Lock：锁的是最大值后的间隙;
  • 如果没走唯一索引，那么就会把所有 聚集索引记录 和 间隙 都锁上，就是所谓的锁表，或叫行锁升表锁.

大于等于

因为 abc_uk >= 10匹配了所有记录，所以你懂的，又锁表了！！！ 具体就不截图了。

我们直接来看不锁表的 abc_uk >= 30

update ct set remark = '阿根廷 3:0 克罗地亚' 
where abc_uk >= 30;

在这里插入图片描述
从上图可知，abc_uk >= 30 和 abc_uk > 20 上的锁是一样的，并不像 id >= 时那样将匹配值优化为Record Lock。

所以，对于 >= 我们得到的结果 实际和 > 一样，不做赘述！

范围组合

说明：索引失效 会 锁表 的规则是通用的，所以这里就 统一 只演示 不锁表 的情况。

范围组合一： > <

update ct set remark = '格子军团' 
where abc_uk > 10 and abc_uk < 20;

在这里插入图片描述
不出所料，由图可知，对 2条唯一索引 和对应的 2条聚集索引 上锁：匹配：15，next-key：20

结果：（和单个规则相同）

  • 如果走了唯一索引：
    • 在该索引上，所有匹配的索引记录 上Next-key Lock，对应的聚集索引 上Record Lock;
    • 向右扫描该索引， 直到找到 [不匹配的索引记录] 上Next-key Lock，对应的聚集索引 上Record Lock.
  • 如果没走唯一索引，那么就会把所有 聚集索引记录 和 间隙 都锁上，就是所谓的锁表，或叫行锁升表锁.

范围组合二： > <=

update ct set remark = '格子军团' 
where abc_uk > 10 and abc_uk <= 20;

》TODO
不出所料，由图可知，对 3条唯一索引 和对应的 3条聚集索引 上锁：匹配：15、20，next-key：30

结果：（和单个规则相同）

  • 如果走了唯一索引：
    • 在该索引上，所有匹配的索引记录 上Next-key Lock，对应的聚集索引 上Record Lock;
    • 向右扫描该索引， 直到找到 [不匹配的索引记录] 上Next-key Lock，对应的聚集索引 上Record Lock.
  • 如果没走唯一索引，那么就会把所有 聚集索引记录 和 间隙 都锁上，就是所谓的锁表，或叫行锁升表锁.

范围组合三： >= <

update ct set remark = '梅西加油' 
where abc_uk >= 10 and abc_uk < 20;

在这里插入图片描述

不出所料，由图可知，对 3条唯一索引 和对应的 3条聚集索引 上锁：匹配：10、15，next-key：20
结果：（和单个规则相同）

  • 如果走了唯一索引：
    • 在该索引上，所有匹配的索引记录 上Next-key Lock，对应的聚集索引 上Record Lock;
    • 向右扫描该索引， 直到找到 [不匹配的索引记录] 上Next-key Lock，对应的聚集索引 上Record Lock.
  • 如果没走唯一索引，那么就会把所有 聚集索引记录 和 间隙 都锁上，就是所谓的锁表，或叫行锁升表锁.

范围组合四： >= <=

update ct set remark = '梅西加油' 
where abc_uk >= 10 and abc_uk <= 15;

在这里插入图片描述
不出所料，由图可知，对 3条唯一索引 和对应的 3条聚集索引 上锁：匹配：10、15，next-key：20
结果：（和单个规则相同）

  • 如果走了唯一索引：
    • 在该索引上，所有匹配的索引记录 上Next-key Lock，对应的聚集索引 上Record Lock;
    • 向右扫描该索引， 直到找到 [不匹配的索引记录] 上Next-key Lock，对应的聚集索引 上Record Lock.
  • 如果没走唯一索引，那么就会把所有 聚集索引记录 和 间隙 都锁上，就是所谓的锁表，或叫行锁升表锁.

唯一索引 小结

对于 唯一索引下的范围查询 <、<=、>、>=，无论是否组合，都会遵循如下规则：

  • 如果走了唯一索引：
    • 在该索引上，所有匹配的 索引记录 上Next-key Lock，对应的聚集索引 上Record Lock;
    • 对于 < 和 <=，会在该索引上向右扫描， 直到找到 [不匹配的索引记录] 上Next-key Lock，对应的聚集索引 上Record Lock;
    • 对于 > 和 >=，会对supremum (上界限伪值) 上Next-key Lock：锁的是 该索引 最大值 后面的 间隙;
  • 如果没走唯一索引，那么就会把所有 聚集索引记录 和 间隙 都锁上，就是所谓的锁表，或叫行锁升表锁.

普通索引

说明：索引失效 会 锁表 的规则是通用的，所以这里就 统一 只演示 不锁表 的情况。

小于

我们在Session2 执行SQL如下（按abc < 20）：

update ct set remark = '梅西加油' 
where abc < 20;

在这里插入图片描述

这里共匹配2条abc=10的记录。

所以共上了 6 把锁，3把锁在普通索引上：

  1. abc = 20 （向右扫描到的第一个不匹配记录）: Next-key Lock；
  2. abc = 10，id = 10（匹配记录） : Next-key Lock；
  3. abc = 10，id = 15（匹配记录） : Next-key Lock；

3把锁在聚集索引上：

  1. id = 20 （向右扫描到的第一个不匹配记录）: Record Lock；
  2. id = 10（匹配记录） : Record Lock；
  3. id = 15（匹配记录） : Record Lock；

可以看出：和唯一索引上锁规则没什么两样!，

锁表只需要把范围扩大就可以复现，比如：

update ct set remark = '梅西加油' 
where abc < 30;

所以，对于 < 在 普通索引 上来说，我们得出的结果是（和唯一索引的 < 相同）：

最后

作为过来人，小编是整理了很多进阶架构视频资料、面试文档以及PDF的学习资料，针对上面一套系统大纲小编也有对应的相关进阶架构视频资料


abc < 20;


![在这里插入图片描述](https://img-blog.csdnimg.cn/8926f79c06d14043a888fdccfb664d91.png)


这里共匹配2条abc=10的记录。


所以共上了 6 把锁，3把锁在**普通索引**上：


1. abc = 20 （向右扫描到的第一个不匹配记录）: Next-key Lock；
2. abc = 10，id = 10（匹配记录） : Next-key Lock；
3. abc = 10，id = 15（匹配记录） : Next-key Lock；


3把锁在**聚集索引**上：


1. id = 20 （向右扫描到的第一个不匹配记录）: Record Lock；
2. id = 10（匹配记录） : Record Lock；
3. id = 15（匹配记录） : Record Lock；


`可以看出：和唯一索引上锁规则没什么两样!`，


**锁表只需要把范围扩大就可以复现**，比如：

update ct set remark = ‘梅西加油’
where abc < 30;


**所以，对于 **<** 在 普通索引 上来说，我们得出的`结果`是（和唯一索引的 < 相同）：**



### 最后

作为过来人，小编是整理了很多进阶架构视频资料、面试文档以及PDF的学习资料，针对上面一套系统大纲小编也有对应的相关进阶架构视频资料

[外链图片转存中...(img-ZutwHlXl-1718782805943)]
[外链图片转存中...(img-cdXQyFNL-1718782805944)]
2401_85111662
关注
  • 18
    点赞
  • 踩
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
mysql锁类型&加锁区间
qq_33300570的博客
09-16 693
前言 InnoDB 通过 MVCC 和 NEXT-KEY Locks，解决了在可重复读的事务隔离级别下出现幻读的问题。 本文主要讲加锁类型及加锁区间 并发处理下的问题 更新丢失 事务T1读取了数据，并执行了一些操作，然后更新数据。事务T2也做处理包含相同行的事，则T1和T2更新数据时可能会覆盖对方的更新，从而引起错误。 更新丢失可以通过加“乐观锁”来解决这个问题。 脏读 脏数据是指事务对缓冲池中的行记录record进行了修改，但是还没提交！如果这时读取缓冲池中未提交的行数据就叫脏读.
mysql 锁范围测试
qq_32682305的博客
07-30 642
测试过得版本有 8.0.18 根据唯一索引、非唯一索引和无索引，以及数据库中是否存在查询边界，进行测试。结果如下，其中边界5存在索引中，边界6不在。数据量新增到7万测试结果还是一样。 表数据如下图： id为主键 userid为二级索引，非唯一 锁范围矩阵（间隙锁是针对insert来说的） 唯一 ...
【MySQL】说透锁机制（二）行锁 加锁规则 之 范围查询（你知道会锁表吗？）
天罡gg的专栏
12-15 4241
本文会按照 聚集集索->唯一索引->普通索引 的顺序 地毯式分析 范围查询中 = 的行锁情况，锁表分析在唯一索引 章节，万字长文，力求分析全面，很硬核全网独一份，别忘了收藏！ 当然如果落下什么欢迎大家评论指出！ 聚集索引 对于 聚集索引下的范围查询 =，无论是否组合，都会遵循如下规则： 所有匹配的索引记录：只有>= 的等值(=)匹配 上Record Lock，其它 上Next-key Lock; 对于 < 和
MySQL锁的类型及加锁范围
xsjzn的博客
08-27 1547
MySQL锁
MYSQL加锁
mywaya2333的博客
11-22 777
mysql加鎖
MySQL锁(表锁,行锁,共享锁,排它锁,间隙锁)使用详解
09-09
MySQL中的锁机制是数据库管理并发访问的关键技术，用于确保数据的一致性和完整性。本文主要讨论了MySQL中的五种锁：表锁、行锁、共享锁、排它锁和间隙锁。 1. 表锁：表锁是MySQL中最基础的锁类型，主要在MyISAM存储...
MySQL InnoDB中的锁机制深入讲解
09-09
MySQL InnoDB 存储引擎的锁机制是数据库并发控制的关键技术，它确保了在多用户环境中数据的一致性和完整性。本文将深入探讨InnoDB的锁类型、锁的使用以及其在处理并发操作时的角色。 首先，InnoDB支持两种类型的锁...
MySQL中的行级锁、表级锁、页级锁
09-10
MySQL数据库管理系统提供了多种锁机制，包括行级锁、表级锁和页级锁，这些锁的使用和理解对于优化并发性能和避免死锁至关重要。 1. 行级锁（Row-Level Locking） 行级锁是MySQL中最细粒度的锁，它只锁定操作的特定...
你真的懂Mysql的锁吗？详谈Myql的锁机制
01-21
要说锁，应该追溯到操作系统中的多线程原理，锁机制在其中发挥着必不可少的作用，先抛出锁的定义 锁是计算机协调多个进程或线程并发访问某一资源的机制 在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用...
MySQL行锁范围分析（行锁、间隙锁、临键锁）
IMLiFeLong
12-10 925
称为写锁，若事务T对对象A加上X锁，则只允许T读取和修改A，其他任何事物都不能再对A 加任何锁，直到T释放A上的锁。SELECT…FOR UPDATE 对读取的行记录加一个X锁，其他事务不能对已锁定的行加上任何锁。
MySQL数据库InnoDB引擎行级锁锁定范围详解
weixin_34304013的博客
02-19 1037
前言 每个数据库几乎都会实现自己的锁机制，锁机制是数据库区别于文件系统的主要标志之一，用于管理对共享资源的并发访问。 Mysql数据库InnoDB引擎支持行级锁，也就是说我们可以对表中某些行数据执行锁定操作，锁定操作的影响是：如果一个事物对表中某行执行了锁定操作，而另一个事务也需要对同样的行执行锁定操作，这样第二个事务的锁定操作有可能...
mysql锁范围（一）表级锁变行级锁
范大的博客
12-18 730
mysql锁范围（一）表级锁变行级锁所有情况
mysql之锁详解
brizer的博客
12-28 1487
锁是计算机协调多个进程或线程访问某一资源的机制。 锁的粒度就是锁的作用范围。数据库中锁的粒度从高到低依次划分为：数据库、表、页、行。 mysql的锁机制比较简单，其最显著的特点是不同的存储引擎支持不同的锁机制。myisam和memory采用的是表级锁，innodb默认采用的是行级锁，但是也支持表级锁。表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发性最低。 行级锁：
Mysql-RR隔离级别-主键范围锁定例子
kongkong的专栏
12-08 743
前言 每次session使用之前，都要设置非自动提交 set session autocommit=0; 查看日志命令 SHOW ENGINE INNODB STATUS ; 脚本 CREATE TABLE `account3` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `username` varchar(20) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL, `age` int(11)
Mysql之加锁规则
jannal专栏
03-09 1287
文章目录锁准备数据等值查询间隙锁非唯一索引等值锁非唯一索引等值锁for Update主键索引范围锁非唯一索引范围锁 锁 MySql只有在RR的隔离级别下才有gap lock和next-key lock 加锁规则 规则1:加锁的基本单位是next-key lock(前开后闭区间) 规则2:查找过程中访问到的对象才会加锁 优化1:索引上的等值查询，给唯一索引加锁的时候，next-key lock...
MySQL间隙锁
laim3的博客
06-21 256
MySQL范围锁 MySQL加锁的基本单位是next-key lock. 只有访问到的对象才会加锁 索引上的等值查询，唯一索引退化为行锁，非唯一索引遍历到最后一个不满足条件的值退化为gap lock 主键范围锁例子 表t, id为主键索引，初始表记录id(10,20,30) select * from t where id >= 10 and id < 20 for update; 加锁范围为 id[10],id(10,20] update t where id = 10 或 id =
MySQL行锁加锁规则之范围查询
最新发布
meser88的博客
03-03 163
这里需要补充说明的是：因为对于范围查询，都会有个边界，所以如果没有任何匹配，就会只对边界加锁，规则不变！结论开篇就给出了，结论传送门如果感觉不错，请，后面还有更详细的锁机制陆续放出。关注我 天罡gg 分享更多干货：大家的「」就是我创作的最大动力！
MYSQL进阶
造梦先森Kai的专栏
08-25 400
左连接包含左表的所有记录，以及与左表匹配的右表中的记录。其中，学生表中的每个记录都与成绩表中符合条件的记录进行了左连接，如果成绩表中没有与学生表匹配的记录，则右表的值为null。sql标签和include标签一般是一起使用的，sql标签中id属性对应include标签中的refid属性。|104 | null | 语文 | 70 || 学号 | 姓名 | 课程 | 分数 ||101 | 张三 | 语文 | 80 ||101 | 张三 | 数学 | 90 ||102 | 李四 | 语文 | 75 |
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值