MySQL-锁

最新推荐文章于 2024-03-09 23:59:08 发布
最新推荐文章于 2024-03-09 23:59:08 发布
阅读量159 收藏
点赞数
分类专栏： 笔记
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/solo_jm/article/details/119180452
版权

锁的结构

锁在内存中的结构如图所示：
在这里插入图片描述
当我们去拿锁的时候，就会在内存中创建一个这样的结构，像上图的结构的产生流程如下：

  1. 事务id为T1的事务，通过sql获取记录的X锁，在内存中就会生成一个锁的结构，结构中记录了事务的信息，并把is_waiting设置为false。
  2. 事务id为T2的事务，通过sql想要获取记录的X锁，发现内存中已经有锁的结构了，于是生成另一个锁的结构，结构中记录了事务的信息，并把is_waiting设置为true。
  3. 当事务id为T1的事务执行完成执行，会把内存中指向该记录的其他内存结构的is_waiting设置为false，并唤醒线程去竞争锁。

快照读和当前读

  1. 快照读：我们执行如SELECT * FROM TABLE，MySQL并不会对这条语句加任何的锁，而是通过MVCC机制读取到数据的快照。
  2. 当前读：通过MySQL的锁机制，读取到最新的数据，加锁。
SELECT * FROM TABLE LOCK IN SHARE MODE
SELECT * FROM TABLE FOR UPDATE
UPDATE
DELETE
INSERT

共享锁（S）和独占锁（X）

  1. 独占锁：指该锁一次只能被一个线程锁持有，通过FOR UPDATE, UPDATE, DELETE, INSERT可加上独占锁，加独占锁之前，锁定资源不能有其他独占锁和共享锁，加锁之后，该资源也不能再被其他线程加上独占锁和共享锁。
  2. 共享锁：值该锁可被多个线程所持有，通过LOCK IN SHARE MODE可以加上共享锁。

意向锁

MySQL在加表级锁的时候，要确认行级锁的情况，比如加表级X锁，就要确保没有任何行级锁（无论是S锁还是X锁），如果遍历去查询，那么性能是非常低的，设计者为了解决这个问题，提出了意向锁的概念。

  1. 意向独占锁（IX）：在要加行级独占锁之前，要先向对应的表挂上意向独占锁。
  2. 意向共享锁（IS）：在要加行级共享锁之前，要先向对应的表挂上意向共享锁。
    这样在加表级锁之前，可以先确定是否存在IX, IS，以此来判断能不能加上表级锁。

表级锁

MySQL的一些存储引擎，像MyIsam、Memory、Merge这些只有表级锁，而且这些存储引擎也并不支持事务，因此在这些存储引擎上加锁，是针对会话的。
比如Session1执行select语句，就相当于对目标表加了一个S锁，Session2执行update语句，就相当于加了X锁。因为有这种特性，所以这些存储引擎不适合用在写频繁的场景下。

InnoDB引擎的表级锁

InnoDB提供的表级锁可以说想当的鸡肋，一般情况下我们都不会用到，如果需要用到可以手动用以下语句加锁：

LOCK TABLES 表名 READ    //加上表级S锁
LOCK TABLES 表名 WRITE   //加上表级X锁

举一个例子，我们执行DML（select、update等）语句，那么我们执行DDL（alter、drop等）就需要阻塞。而我们执行DDL（alter、drop等），在执行DML（select、update等）语句，也需要阻塞。
乍一看，好像用了表级锁来控制，然而并不是，MySQL压根没用InnoDB的表级锁，而是在server层使用了一种在称为元数据锁的东西。

IS意向锁和IX意向锁

这两种锁都是加在表上的，主要是用来加表锁时快速的判断表内行级锁的情况。

表级别AUTO-INC锁

我们给表的某一列加上AUTO_INCREMENT在插入数据的时候，我们就可以不用指定该列的值，MySQL会自动给我们插入对应的值，该值的获取 -> 加一操作是要保证原子性的，InnoDB通过表级别的AUTO-INC锁来保证这个操作的原子性。
具体来说，先获取AUTO-INC锁，把值赋个该列，执行插入，释放AUTO-INC锁。
我们可以看到AUTO-INC锁的释放要在整个语句执行完毕，在我们不清楚插入记录数量的时候，就必须要通过AUTO-INC锁来保证自增列的原子性。
假如我们已经确定插入记录的数量，那么就可以不用AUTO-INC锁了，可以用一种轻量级锁，具体操作可以变为先获取AUTO-INC锁，把值赋个该列，释放AUTO-INC锁，执行插入。

元数据锁

元数据锁主要是面向DML和DDL之间的并发控制，如果对一张表做DML增删改查操作的同时，有一个线程在做DDL操作，不加控制的话，就会出现错误和异常。元数据锁不需要我们显式的加，系统默认会加。
当做DML操作时，会申请一个MDL读锁。
当做DDL操作时，会申请一个MDL写锁。
读锁之间不互斥，读写和写写之间都互斥。

行级锁

record lock

我们常说的行级锁就是指的这个类型record lock的行级锁，record lock分为S型record lock和X型record lock，这种锁是作用在记录级别的。
我们给一条记录加上X型record lock，其他线程就不能在这条记录上加S型record lock和X型record lock。给一条记录加上S型record lock，其他线程可以加S型record lock，但是不能加上X型record lock。

gap lock

gap lock，称为间隙锁，MySQL在REPEATABLE READ隔离级别下用该锁来解决幻读的问题。假如我们有以下表：
在这里插入图片描述
实际上，在页中这些记录的存储都是连续的并没有像图中显示的这样有间隙，这里只是为了方便理解。
假如我们给id为8的记录加上gap锁，那么这条记录往前的区间（3,8）也会加锁。
id为8的记录往后到+∞也有着一个区间（8,+∞），这一个区间的加上gap锁要依靠最后一条记录所在页的supremum行。

Next-Key lock

Next-Key lock是record lock和gap lock的组合，比如我们给id为8的记录加上Next-Key lock，那么会给id为8的记录加上record lock，并且给区间(3, 8)加上gap lock。

Insert Intention Lock

我们说MySQL的gap lock可以解决幻读的问题，假如我们在id为8的记录加上gap lock或者Next-Key lock，那么区间（3,8）也会被锁上，我们就没办法往这个区间插入数据，当我们尝试往这个区间插入数据时，会生成一个Insert Intention Lock结构（意向间隙锁），该结果会指向这条记录。
在这里插入图片描述
产生图上结构的锁流程如下：

  1. trx为T1的事务，为id为8的记录加上gap lock或者Next-Key lock，区间（3,8）也会被锁上。
  2. trx为T2的事务，想插入id为4的记录，trx为T3的事务，想插入id为5的记录，由于区间（3,8）被锁上，因此内存中产生了两个锁的结构，请求插入的线程被阻塞。
  3. trx为T1的事务执行结束，释放间隙锁，并把内存中T2,T3的锁结构的is_waiting改为false，唤醒T2,T3的线程。

隐式锁

在MySQL用锁就意味着要有对应的内存结构，对这种资源的消耗，MySQL的设计者也是能省就省，在INSERT一条记录之后，MySQL不会有任何的锁结构，哪怕插入数据的事务还没有结束，那么假如其他的事务要读取这条记录，就会出现脏读（还没提交，就可以读到）。
一般来说，我们插入一条数据，然后别的事务立刻来读的情况发生的可能性不高，但是也不是完全不会发生，MySQL设计者肯定不能容忍这样的错误。
我们先假设出现这样问题的流程如下：

  1. 事务T2插入了id为4的记录，但是事务T2还没有结束。
  2. 事务T3通过LOCK IN SHARE MODEL或者FOR UPDATE查询读取id为4的记录，想要去加锁。
    MySQL是这样解决的，事务T3读取的时候会生成READVIEW，READVIEW中有一个活跃事务集合，但是事务T3发生要上锁的记录中记录的trx_id（本例是T2）存在活跃事务集合中，那么就会进行以下操作：
  3. 在内存中生成一个锁结构，trx_id为T2，is_waiting为false
  4. 在内存中给自己生成一个锁结构，trx_id为T3，is_waiting为true
  5. 阻塞等待
    在事务T2结束的时候，正常情况下内存中是没有该事务的锁结构的，如果有，证明有事务在等着给该记录上锁，那么就要释放掉自己的锁结构，再把trx_id为T3的锁结构的is_waiting改为false，然后唤醒对应的线程。

行锁升级为表锁

InnoDB行级锁是通过给索引上的索引项加锁来实现的，InnoDB行级锁只有通过索引条件检索数据，才使用行级锁；否则，InnoDB使用表锁。

锁的结构优化

我们前面说了非常简化的锁的结构（只提到了is_waiting，事务信息，type）的时候说过事务在给记录加锁的时候会在内存中就会生成一个锁的结构，那么如果一条sql需要给多给记录加锁应该如何处理呢？总不能有10000条记录就生成10000个锁结构吧。
为了解决这个问题，MySQL的设计提出了多条记录共有一个锁结构的概念，设计者决定只要满足以下条件就可以共有一个锁结构：

  1. 在一个事务内。
  2. 在一个页面内。
  3. 锁类型相同。
  4. 锁的属性相同。
    我们现在聊聊更加详细的锁结构，从中理解MySQL是如何解决加锁多个记录的，如图所示：
    在这里插入图片描述
  5. 锁所在的事务信息：这里保存的是一个指针，指向具体的事务信息。
  6. 索引信息：加锁的记录属于哪一个索引。
  7. 表锁/行锁信息：该段保存的信息跟锁的类型有关。
    （1）表锁：存储表的信息，如是对哪个表加的锁。
    （2）行级锁：
    *Space ID：记录所在表空间ID。
    *Page Number：记录所在页面的页号。
    *n_bits：记录后面一堆比特位区域具体比特的数量。
  8. type_mode：由一块32比特的区域组成，如下：
    在这里插入图片描述
    （1）lock_mode：LOCK_IS(0), LOCK_IX(1), LOCK_S(2), LOCK_X(3), LOCK_AUTO_INC(4)。
    （2）lock_type：LOCK_TABLE(16), LOCK_RECORD(32)。
    （3）lock_wait：第九位为1时，is_waiting为true，is_waiting为false。
    （4）record_lock_type：LOCK_GAP(512), LOCK_REC_NOT_GAP(1024), LOCK__INSERT_INTENTION(2048)。
  9. 一堆比特位：如布隆过滤器一样，每一位代表为1，表示要加锁的记录在页中对应的位置，当然MySQL会准备比实际记录行数更多的比特位，主要是怕页中记录的增加。

普通的SELECT

  1. 读未提交：每次都读取最新的数据，有脏读，不可重复读，幻读的问题。
  2. 读已提交：每次SELECT都会生成新的READVIEW，有不可重复读，幻读的问题。
  3. 可重复读：第一次SELECT的时候会生成READVIEW，可以解决大部分幻读的问题。
    MVCC怎么解决幻读问题：按照READVIEW的原理，会生产一个活跃事务ID的集合，如果一个插入事务已经拥有了事务ID，那么它必定在活跃事务集合内，不可读，如果是READVIEW产生之后，插入事务才开启执行插入（这个时候才生成事务ID），那么它的事务ID必定大于活跃事务集合的最大ID，所以也是不可读。
    MVCC无法解决全部的幻读问题：我们知道在第一次SELECT的时候产生READVIEW，如果一个事务T1执行了一次查询产生了READVIEW，接着有另一个事务T2执行了INSERT，然后提交，我们知道事务T2的ID一定在T1的活跃事务ID的集合中合着大于活跃事务ID的集合的最大ID，假如事务T1再去SELECT肯定读不到，但是假如事务T1先执行一个UPDATE操作，因为事务T2已经提交了，按照隐式锁的概念只要插入事务提交了，那么事务T1就可以UPDATE这条记录，那么事务ID就会变成T1，之后T1在执行SLECT就可以读取到这条记录了
  4. 可串行化：
    （1）autocommit为1时：不需要借助锁，通过MVCC的机制就可以解决全部的问题。
    （2）autocommit为0时：普通的SELECT会被转为LOCK IN SHARE MODE的S锁。

语句加锁分析

我们前面说了许多锁的东西，但是始终没有聊到record lock、gap lock和next-key lock这几个锁MySQL是怎么样使用的，我们现在就来说以下语句MySQL是如何操作的：

  1. LOCK IN SHARE MODE
  2. FOR UPDATE
  3. UPDATE
  4. DELETE
    我们先假设以下结构，ID为主键，key为二级索引。
    在这里插入图片描述

LOCK IN SHARE MODE和FOR UPDATE

这两个语句本质上的原理没有太大的区别，只不过FOR UPDATE加的锁是X型的，LOCK IN SHARE MODE加的锁是S型的，所以我们只分析LOCK IN SHARE MODE的操作。

使用聚簇索引

不同的隔离级别在使用锁和操作上会有很大的差异，现在执行以下语句：

SELECT * FROM TABLE WHERE id > 1 and id <= 15 and col = true;

该语句会形成区间(1, 15]。

READ UNCOMMITTED和READ COMMITTED
  1. 找到满足区间的第一条数据，也就是id = 3的记录。
  2. 给id = 3的记录加上S型的record lock。
  3. 由于读取的是聚簇索引，所以没有索引下推的判断。
  4. 由于读取的是聚簇索引，所以不需要进行回表的操作。
  5. 形成区间(1, 15]的条件是id > 1 and id <= 15，很显然id = 3是满足的，存储引擎返回数据给server。
  6. server进一步进行条件id > 1 and id <= 15 and col = true的判断，id = 3的记录满足该条件，所以把记录返回客户端，锁不会释放。
  7. 获取id = 3记录的下一条记录。
    为id = 8的记录进行加锁分析：
  8. 给id = 8的记录加上S型的record lock。
  9. 由于读取的是聚簇索引，所以没有索引下推的判断。
  10. 由于读取的是聚簇索引，所以不需要进行回表的操作。
  11. 形成区间(1, 15]的条件是id > 1 and id <= 15，很显然id = 8是满足的，存储引擎返回数据给server。
  12. server进一步进行条件id > 1 and id <= 15 and col = true的判断，id = 8的记录满足该条件，所以把记录返回客户端，锁不会释放。
  13. 获取id = 8记录的下一条记录。
    为id = 15的记录进行加锁分析：
  14. 给id = 15的记录加上S型的record lock。
  15. 由于读取的是聚簇索引，所以没有索引下推的判断。
  16. 由于读取的是聚簇索引，所以不需要进行回表的操作。
  17. 形成区间(1, 15]的条件是id > 1 and id <= 15，很显然id = 15是满足的，存储引擎返回数据给server。
  18. server进一步进行条件id > 1 and id <= 15 and col = true的判断，id = 15的记录不满足该条件，所以释放掉该记录上加的S型record lock。
  19. 获取id = 15记录的下一条记录。
    为id = 20的记录进行加锁分析：
  20. 给id = 20的记录加上S型的record lock。
  21. 由于读取的是聚簇索引，所以没有索引下推的判断。
  22. 由于读取的是聚簇索引，所以不需要进行回表的操作。
  23. 形成区间(1, 15]的条件是id > 1 and id <= 15，很显然id = 20是不满足的，释放掉S型record lock，并返回“查询完毕”的信息给server。
  24. server收到“查询完毕”的信息，结束查询。
    以上步骤会形成如下加锁图示：
    在这里插入图片描述
REPEATABLE READ和SERIALIZABLE
  1. 找到满足区间的第一条数据，也就是id = 3的记录。
  2. 给id = 3的记录加上S型的next-key lock。
  3. 由于读取的是聚簇索引，所以没有索引下推的判断。
  4. 由于读取的是聚簇索引，所以不需要进行回表的操作。
  5. 形成区间(1, 15]的条件是id > 1 and id <= 15，很显然id = 3是满足的，存储引擎返回数据给server。
  6. server进一步进行条件id > 1 and id <= 15 and col = true的判断，id = 3的记录满足该条件，所以把记录返回客户端，锁不会释放。
  7. 获取id = 3记录的下一条记录。
    为id = 8的记录进行加锁分析：
  8. 给id = 8的记录加上S型的next-key lock。
  9. 由于读取的是聚簇索引，所以没有索引下推的判断。
  10. 由于读取的是聚簇索引，所以不需要进行回表的操作。
  11. 形成区间(1, 15]的条件是id > 1 and id <= 15，很显然id = 8是满足的，存储引擎返回数据给server。
  12. server进一步进行条件id > 1 and id <= 15 and col = true的判断，id = 8的记录满足该条件，所以把记录返回客户端，锁不会释放。
  13. 获取id = 8记录的下一条记录。
    为id = 15的记录进行加锁分析：
  14. 给id = 15的记录加上S型的next-key lock。
  15. 由于读取的是聚簇索引，所以没有索引下推的判断。
  16. 由于读取的是聚簇索引，所以不需要进行回表的操作。
  17. 形成区间(1, 15]的条件是id > 1 and id <= 15，很显然id = 15是满足的，存储引擎返回数据给server。
  18. server进一步进行条件id > 1 and id <= 15 and col = true的判断，id = 15的记录不满足该条件，锁不会释放。
  19. 获取id = 15记录的下一条记录。
    为id = 20的记录进行加锁分析：
  20. 给id = 20的记录加上S型的next-key lock。
  21. 由于读取的是聚簇索引，所以没有索引下推的判断。
  22. 由于读取的是聚簇索引，所以不需要进行回表的操作。
  23. 形成区间(1, 15]的条件是id > 1 and id <= 15，很显然id = 20是不满足的，不释放S型next-key lock，并返回“查询完毕”的信息给server。
  24. server收到“查询完毕”的信息，结束查询。
    以上步骤会形成如下加锁图示：
    在这里插入图片描述
    由于是用next-key lock加的锁，所以区间(1,3),(3,8),(8,15),(15,20)都会被锁上（gap锁）。

使用二级索引

执行以下语句：

SELECT * FROM TABLE WHERE key > 'a' and key <= 'd' and col = true;

该语句会形成区间(‘a’, ‘d’]。

READ UNCOMMITTED和READ COMMITTED
  1. 读取第一条满足区间(‘a’, ‘d’]的二级索引记录，也就是key = 'b’的二级索引记录。
  2. 给该二级索引记录加上S型record lock。
  3. 索引下推，是否满足key > ‘a’ and key <= ‘d’，key = 'b’的二级索引记录明显是满足的。
  4. 进行回表，拿到id = 8的聚簇索引记录，并给该id = 8的记录加上S型record lock。
  5. 形成区间(‘a’, ‘d’]的条件是key > ‘a’ and key <= ‘d’，很显然id = 8是满足的，存储引擎返回数据给server。
  6. server判断其他条件col = true是否满足，id = 8的记录是满足的，因此把数据返回给客户端，锁不会释放。
  7. 获取key = 'b’的二级索引记录的下一条记录。
    为key = 'c’的记录进行加锁分析：
  8. 给key = 'c’的二级索引记录加上S型record lock。
  9. 索引下推，是否满足key > ‘a’ and key <= ‘d’，key = 'c’的二级索引记录明显是满足的。
  10. 进行回表，拿到id = 1的聚簇索引记录，并给该id = 1的记录加上S型record lock。
  11. 形成区间(‘a’, ‘d’]的条件是key > ‘a’ and key <= ‘d’，很显然id = 1是满足的，存储引擎返回数据给server。
  12. server判断其他条件col = true是否满足，id = 1的记录是满足的，因此把数据返回给客户端，锁不会释放。
  13. 获取key = 'c’的二级索引记录的下一条记录。
    为key = 'd’的记录进行加锁分析：
  14. 给key = 'd’的二级索引记录加上S型record lock。
  15. 索引下推，是否满足key > ‘a’ and key <= ‘d’，key = 'd’的二级索引记录明显是满足的。
  16. 进行回表，拿到id = 15的聚簇索引记录，并给该id = 15的记录加上S型record lock。
  17. 形成区间(‘a’, ‘d’]的条件是key > ‘a’ and key <= ‘d’，很显然id = 15是满足的，存储引擎返回数据给server。
  18. server判断其他条件col = true是否满足，id = 15的记录是不满足的，因此释放掉聚簇索引和二级索引上的锁。
  19. 获取key = 'd’的二级索引记录的下一条记录。
    为key = 'f’的记录进行加锁分析：
  20. 给key = 'f’的二级索引记录加上S型record lock。
  21. 索引下推，是否满足key > ‘a’ and key <= ‘d’，key = 'd’的二级索引记录明显是不满足的，直接返回“查询完毕”的信息给server。
  22. server收到“查询完毕”的信息，结束查询。
    以上步骤会形成如下加锁图示：
    在这里插入图片描述
REPEATABLE READ和SERIALIZABLE
  1. 读取第一条满足区间(‘a’, ‘d’]的二级索引记录，也就是key = 'b’的二级索引记录。
  2. 给该二级索引记录加上S型next-key lock。
  3. 索引下推，是否满足key > ‘a’ and key <= ‘d’，key = 'b’的二级索引记录明显是满足的。
  4. 进行回表，拿到id = 8的聚簇索引记录，并给该id = 8的记录加上S型record lock。
  5. 形成区间(‘a’, ‘d’]的条件是key > ‘a’ and key <= ‘d’，很显然id = 8是满足的，存储引擎返回数据给server。
  6. server判断其他条件col = true是否满足，id = 8的记录是满足的，因此把数据返回给客户端，锁不会释放。
  7. 获取key = 'b’的二级索引记录的下一条记录。
    为key = 'c’的记录进行加锁分析：
  8. 给key = 'c’的二级索引记录加上S型next-key lock。
  9. 索引下推，是否满足key > ‘a’ and key <= ‘d’，key = 'c’的二级索引记录明显是满足的。
  10. 进行回表，拿到id = 1的聚簇索引记录，并给该id = 1的记录加上S型record lock。
  11. 形成区间(‘a’, ‘d’]的条件是key > ‘a’ and key <= ‘d’，很显然id = 1是满足的，存储引擎返回数据给server。
  12. server判断其他条件col = true是否满足，id = 1的记录是满足的，因此把数据返回给客户端，锁不会释放。
  13. 获取key = 'c’的二级索引记录的下一条记录。
    为key = 'd’的记录进行加锁分析：
  14. 给key = 'd’的二级索引记录加上S型next-key lock。
  15. 索引下推，是否满足key > ‘a’ and key <= ‘d’，key = 'd’的二级索引记录明显是满足的。
  16. 进行回表，拿到id = 15的聚簇索引记录，并给该id = 15的记录加上S型record lock。
  17. 形成区间(‘a’, ‘d’]的条件是key > ‘a’ and key <= ‘d’，很显然id = 15是满足的，存储引擎返回数据给server。
  18. server判断其他条件col = true是否满足，id = 15的记录是不满足的，锁不会释放。
  19. 获取key = 'd’的二级索引记录的下一条记录。
    为key = 'f’的记录进行加锁分析：
  20. 给key = 'f’的二级索引记录加上S型next-key lock。
  21. 索引下推，是否满足key > ‘a’ and key <= ‘d’，key = 'd’的二级索引记录明显是不满足的，直接返回“查询完毕”的信息给server。
  22. server收到“查询完毕”的信息，结束查询。
    以上步骤会形成如下加锁图示：
    在这里插入图片描述

精确匹配

READ UNCOMMITTED和READ COMMITTED下的精确匹配之后给对应的记录加上record lock，REPEATABLE READ和SERIALIZABLE该对应记录的加上record lock，并把记录前后区间加上gap lock。通过这个特性我们要是想锁定区间（20，正无穷）的间隙，可以用id = 21或者以上的条件来锁定。

UPDATE

UPDATE的操作和FOR UPDATE的加锁类似，只是如果是在聚簇索引上加锁，有二级索引的话要获取对应二级索引的锁。

半一致性读

在做UPDATE的时候如果是READ UNCOMMITTED和READ COMMITTED，发现记录被上锁了，会被记录最新的版本读出来，先进行判断，如果不满足直接跳到下一个记录，如果满足在加锁，这样可以减少UPDATE被阻塞。

查看加锁情况

使用information_schema数据库中的表获取锁信息

SELECT * FROMG information_schema.INNODB_TRX;

使用SHOW ENGINE INNODB STATUS获取锁信息

SELECT ENGINE INNODB STATUS;
一只小P熊
关注
专栏目录
深入理解SELECT ... LOCK IN SHARE MODE和SELECT ... FOR UPDATE
standb的博客
11-07 696
概念和区别 SELECT … LOCK IN SHARE MODE走的是IS锁(意向共享锁)，即在符合条件的rows上都加了共享锁，这样的话，其他session可以读取这些记录，也可以继续添加IS锁，但是无法修改这些记录直到你这个加锁的session执行完成(否则直接锁等待超时)。 SELECT … FOR UPDATE 走的是IX锁(意向排它锁)，即在符合条件的rows上都加了排它锁，其他session也就无法在这些记录上添加任何的S锁或X锁。如果不存在一致性非锁定读的话，那么其他session是无法读取
SHOW ENGINE INNODB STATUS 结果解释解读（事务部分）
努力不掉队的DBA
09-16 2839
SHOW ENGINE INNODB STATUS 事务锁查看 学习笔记 + 分享 我们都知道，通过show engine innodb status\G这条命令可以查看当前事务内锁的状态。 但是呈现出来的参数是什么意思？本文将简单介绍，如果错误，欢迎广大网友指出。 如果作者本人不太清楚的地方也做了标记，表示是从网络上查看别人的文章截取的，针对这一部分内容大家最好自己核对一下。 版本 & 参数 版本：mysql-5.7.31 参数： innodb_status_output_locks=
mysql-5.7 show engine innodb status 详解
weixin_34315189的博客
09-10 6550
一、show engine innodb status 简介： 　　show engine innodb status 是mysql提供的一个用于查看innodb引擎时间信息的工具，就目前来说有两处比较 　　常用的地方一、死锁分析 二、innodb内存使用情况   二、通过show engine innodb status 查看内存使用情况： 　　1、show variables like 'in...
Mysql行锁、表锁 (2)—mysql进阶（六十九)
ke1ying的博客
10-22 1082
前面说了解决并发事务访问有两种解决办法，一种用mvcc的版本链解决，读 的时候用版本链readView控制，写的时候加锁。一种是读写都加锁，比如只允许读取最后数据的银行业务。锁又分为共享锁（s锁）和排它锁（x锁），锁的颗粒度分为表锁和行锁，所以当向上表的排他锁的时候，必须里面的行没有上x锁或者s锁，当然不是遍历所有行，于是在上行锁的时候，会有一个is和ix的锁，代表当前表上了行锁。 Mysql锁共享锁排它锁 (1)—mysql进阶（六十八) 行锁、表锁 我们主要说的是innoDB存储引擎的锁，其
MySQL-锁表和解锁
热门推荐
weixin_45203607的博客
02-19 1万+
介绍 锁是计算机协调多个进程或线程并发访问某一资源的机制。锁保证数据并发访问的一致性、有效性；锁冲突也是影响数据库并发访问性能的一个重要因素。锁是Mysql在服务器层和存储引擎层的的并发控制。 加锁是消耗资源的，锁的各种操作，包括获得锁、检测锁是否是否已解除、释放锁等。 锁机制 共享锁与排他锁 共享锁（读锁）：其他事务可以读，但不能写。 排他锁（写锁） ：其他事务不能读取，也不能写。 粒度锁 MySQL 不同的存储引擎支持不同的锁机制，所有的存储引擎都以自己的方式显现了锁机制，服务器层完全不了解存储引擎中的
MySQL - 锁机制初探
小工匠
08-11 1万+
文章目录Pre锁的分类InnoDB 中的锁行锁InnoDB 行锁的三种算法实现表锁InnoDB 自增锁InnoDB 锁关系矩阵InnoDB 锁问题排查思路 Pre MySQL - 解读MySQL事务与锁机制 MySQL - 共享锁和排它锁初探 MySQL - 无索引行锁升级为表锁 MySQL - 锁等待及死锁初探 锁的分类 在 MySQL 中有三种级别的锁：页级锁、表级锁、行级锁 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。 会发生在：MyISAM、memor
MySQL - 锁
迟迟 CSDN
12-23 2894
一、什么是锁 锁是数据库系统区别于文件系统的一个关键特性。锁机制用于管理对共享资源的并发访问。 二、MySQL 不同存储引擎支持的锁机制 存储引擎 支持的锁类型 Myisam 表锁 Innodb 行锁、表锁 Memory 表锁 BDB 页锁、表锁 　表锁：直接锁住的是一个表，开销小，加锁快，不会出现死锁的情况，锁定粒度大，发生锁...
【MySQL】MySQL-锁等待（Waiting for table metadata lock）
tttzzzqqq2018的博客
03-06 1644
MySQL 5.6，使用方法1处理MySQL 5.7，先判断是否开启了metadata_locks表特性，如果开启了使用方法2，否则使用方法1MySQL 8.0，使用方法2及时提交或者缩短SQL执行时间（优化SQL），可以减少Waiting for table metadata lock出现次数。
MySQL-锁：共享锁（读）、排他锁（写）、表锁、行锁、意向锁、间隙锁，锁升级
小孔靠得住的博客
03-09 1819
在MySQL中，锁升级是指事务在执行过程中，将当前持有的锁从低级别升级到更高级别的过程。MySQL数据库中的锁是控制并发访问的重要机制，它们确保数据的一致性和完整性。因此，在这种场景下，合理使用共享锁和排他锁可以确保数据的完整性和一致性，避免潜在的并发问题。为1的产品行的共享锁，但在后续执行中需要对该行进行修改，因此需要将共享锁升级为排他锁。为100的订单行的意向排他锁，后续执行了删除操作，需要将意向锁升级为表级锁。
MySql-锁机制个人总结
05-07
MySql-锁机制个人总结
mysql-server-mysql-8.3.0.tar.gz
最新发布
03-28
2. **InnoDB存储引擎优化**：InnoDB是MySQL默认的事务处理引擎，8.3.0版本可能会进一步优化其性能，包括更快的索引构建、更高效的锁机制以及更好的内存管理。 3. **窗口函数**：这是MySQL 8.0引入的新特性，允许在...
mysql-server-mysql-5.7.36.tar.gz
09-16
4. **增强的性能监控**：通过Performance Schema，用户可以更深入地了解数据库的运行情况，包括锁、线程、内存使用等，从而进行更有效的性能调优。 5. **柱状图索引（CTE）**：引入了Common Table Expressions（CTE...
mysql-8.0.21-winx64.zip.zip
10-29
8. **优化的DML操作**：对INSERT、UPDATE和DELETE语句的处理进行了优化，减少了锁的使用，提高了并发性能。 9. **更好的备份和恢复**：提供了改进的备份工具和策略，如InnoDB表空间的在线备份，以及对逻辑备份的...
Redis Ziplist（压缩列表）
solo_jm的博客
07-06 3197
简述 ziplist是Redis list、hash、zset的底层实现结构之一，当list、hash、zset中节点数量较少，并且存储的大多节点为小整数型，较短的字符串时，Redis就会使用ziplist作为list、hash、zset的底层实现。 牺牲时间换取空间 拿list来说，实现有双向链表、ziplist。当实现为双向链表时，节点会有pre和next指针，每一个指针占8个字节。而ziplist的entry中，用previous_entry_length保存上一个entry的长度，当上一个entry
Dubbo注册中心
solo_jm的博客
09-18 2224
注册中心概述 假如我们在服务消费者端维护了一个服务提供者的列表，在没有注册中心的情况下，假如新增了一个服务提供者或者某一个提供者下线了，都要去更新服务消费者的配置文件。 引入注册中心之后，就可以实现分布式服务的注册与发现，注册中心是分布式系统的枢纽，其主要作用有如下几点： 动态加入。 一个服务提供者通过注册中心可以动态地把自己暴露给其他消费者， 无须消费者逐个去更新配置文件。 动态发现。 一个消费者可以动态地感知新的配置、 路由规则和新的服务提供者， 无须重启服务使之生效。 动态调整。 注册中心支持参数的
计算机网络-传输层
solo_jm的博客
09-07 2022
传输层概述 通过网络层、数据链路层和物理层可以建立起主机和主机之间的连接，但是实际上网络上的通讯都是主机应用程序和应用程序之间的通讯，IP数据报达到目的地之后要分发给不同的应用程序，这就是传输层的工作。 Socket Socket套接字位于应用层和传输层之间，作为应用层和传输层通讯的通道。 多路复用和多路分解 多路复用：应用层产生的应用报文通过传输层的TCP/UDP协议会被封装成为应用数据报（UDP）、报文段（TCP），之后通过网络层的IP协议进一步封装成为IP数据报，IP数据报头部的协议字段会标记这
MySQL-段、区、组
solo_jm的博客
07-21 1895
区 如果我们有大量的记录，那么表空间中页的数量就会非常的多，为了更好的管理这些页，设计者又提出了区的概念。对于16KB的页来说，连续的64个页（连续的）就是一个区，也就是说一个区的大小为1MB。（256个区被划分成一个组） 为什么需要区 通过页其实已经形成了完整的功能，我们查询数据时这样沿着双向链表就可以查到数据，但是页与页之间在物理位置上可能不是连续的，如果相隔太远，那么我们从一个页移动到另一个页的时候，磁盘就要重新定义磁头的位置，产生随机IO，影响性能，所以我们才要引入区的概念，一个区就是物理位置连续的
计算机网络-DNS
solo_jm的博客
08-28 1333
什么是DNS 域名系统DNS（Domain Name System）是互联网使用的命名系统，用来把便于人们使用的机器名字转换为IP地址。 为什么不直接用域名，而要用IP IP长度是固定的，而域名的长度是不固定的，对于计算机来说处理IP会更加方便简单，而对于人来说，使用域名比使用IP更加方便简单。 简单的工作原理 在浏览器中输入www.baidu.com。 浏览器从上述URL中抽取出主机名www.baidu.com，并将这台主机名传给DNS应用的客户端，每个计算机都有DNS客户端，用来与DNS服务器通讯。
MySQL读写锁实战解析
"这篇文档是关于MySQL数据库中的读写锁的演示案例，旨在帮助读者深入理解读写锁的概念和特性。文档通过实际操作演示了如何对表加读锁和写锁，并介绍了这两种锁的不同影响。" 在MySQL数据库中，读写锁是一种用于并发...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值