临键锁（Next-Key Lock）：临键锁是查询时InnoDB根据查询的条件而锁定的一个范围，这个范围中包含有间隙锁和记录锁；临键锁=间隙锁+记录锁。
记录锁也就是仅仅把一条记录锁上，官方的类型名称为： LOCK_REC_NOT_GAP 。比如我们把id值为8的 那条记录加一个记录锁的示意图如图所示。仅仅是锁住了id值为8的记录，对周围的数据没有影响。
文件锁是用于解决资源的共享使用的一种机制：当多个用户需要共享一个文件时，Linux通常采用的方法是给文件上锁，来避免共享的资源产生竞争的状态。
有小伙伴在微信上表示面试时被问到了 Next-Key Lock 是啥，结果一脸懵逼，那么今天我们来捋一捋 MySQL 中的记录锁、间隙锁以及 Next-Key Lock。 1. Record Lock Record Lock 也就是我们所说的记录锁，记录锁是对索引记录的锁，注意，它是针对索引记录，即它只锁定记录这一行数据。 例如如下一条 SQL： select * from user where id=1 for update; 注意，id 是索引，id 如果不是索引，上面这条 SQL 所加的排他锁就不是一
面试官反问的大概意思是，MySQL 记录锁+间隙锁可以防止删除操作而导致的幻读吗？
除了以上三类，排他锁（X）还包含另一类有点特殊的锁，就是插入意向锁（LOCK_INSERT_INTENTION）。
通过之前的open()/close()/read()/write()/lseek()函数已经可以实现文件的打开、关闭、读写等基本操作，但是这些基本操作是不够的。
Record Lock 称为记录锁，锁住的是一条记录。而且记录锁是有 S 锁和 X 锁之分的：
在前一篇文章我讲了下 MySQL 的全局锁、表记锁和行级别锁，其中行级锁只提了概念，并没有具体说。
在上一篇文章《锁的类型以及加锁原理》主要总结了 MySQL 锁的类型和模式以及基本的加锁原理，今天我们就从原理走向实战，分析常见 SQL 语句的加锁场景。了解了这几种场景，相信小伙伴们也能举一反三，灵活地分析真实开发过程中遇到的加锁问题。
单个记录上的锁。记录锁始终锁定索引记录本身，即使没有定义索引的表也是如此。对于这种情况，InnoDB创建一个隐藏的聚簇索引，并将该索引用于记录锁定。
数据也是一样，在并发的场景下，如果不对数据加锁，会直接破坏数据的一致性，并且如果你的业务涉及到钱，那后果就更严重了。
表锁是指锁定时锁定整个表，下一个事务访问该表时，必须等到上一个事务解除锁定后再访问表
MySQL 作为使用范围最广的开源关系型数据库，是每个后端开发人员都绕不开的一道坎。我在上一篇文章中也写了关于 MySQL 中的 MVCC 的细节及各个隔离级别如何使用 MVCC，有兴趣的可以查看。
本文是用来系统阐述在MySQL中，不同语句在各种条件下的加锁情况，并不是解释各种锁是什么（或者说加锁的本质是什么）
今天做了个简单的死锁测试，当3个会话中同时进行同一条insert语句时，回滚其中一条，另外两条会发生死锁。
默认情况下，InnoDB工作在可重复读隔离级别下，并且会以Next-Key Lock的方式对数据行进行加锁，这样可以有效防止幻读的发生。Next-Key Lock是行锁和间隙锁的组合，当InnoDB扫描索引记录的时候，会首先对索引记录加上行锁（Record Lock），再对索引记录两边的间隙加上间隙锁（Gap Lock）。加上间隙锁之后，其他事务就不能在这个间隙修改或者插入记录。
上一篇文章介绍了数据库中锁的起源，今天将介绍数据库中常用的锁。还是以MySQL为例，MySQL中有表锁、行锁、共享锁、互斥锁、意向锁、间隙锁、记录锁、Next-Key锁、插入意向锁、AUTO-INC锁、隐式锁。看完本篇文章，再多的锁都难不倒你。
有关Mysql记录锁、间隙(gap)锁、临键锁(next-key)锁的一些理论知识之前有写过，详细内容可以看这篇文章 一文详解MySQL的锁机制
其实啊，“XXX语句该加什么锁”本身就是个伪命题，一条语句需要加的锁受到很多条件制约，比方说：
我们为hero表的id列创建了聚簇索引，为name列创建了一个二级索引。这个hero表主要是为了存储三国时的一些英雄，我们向表中插入一些记录：
在上篇文章，我们聊了「MySQL 啥时候会用表锁，啥时候用行锁」这个问题。在文章中，我们还留了一个问题，即：如果查询或更新时的数据特别多，是否从行锁会升级为表锁？此外，还有朋友留言说到：不同的隔离级别可能会用不同的锁，可以结合隔离级别来聊聊。
锁是计算机用以协调多个进程间并发访问同一共享资源的一种机制。MySQL中为了保证数据访问的一致性与有效性等功能，实现了锁机制，MySQL中的锁是在服务器层或者存储引擎层实现的。
之前的一篇文章 《深入理解MySQL的MVCC原理》中总结了一下MySQL中的MVCC，它主要利用隐藏字段、版本链、ReadView来实现，可以用来更好地解决多个事务的并发【读+写】问题，但是如果在多个事务并发【写+写】的情况下，就必须要用到锁了，一般情况下，数据库的锁都是在有数据库操作的过程中自动添加的。
最近在学习查找MySQL中"锁"的相关资料时，发现网上各种言论观点杂乱不堪且版本混乱，很容易让人深陷其中、很是蒙圈。笔者认真研读了MySQL8.0官方指导手册，并广泛搜集各家观点，整理了一份参考性较强的关于MySQL中"锁"机制的知识点合集，以供参考学习。
在 第20篇 和 第21篇 文章中，我和你介绍了 InnoDB 的间隙锁、next-key lock，以及加锁规则，在这两篇文章的评论区，出现了很多高质量的留言，我觉得通过分析这些问题，可以帮助你加深对加锁规则的理解。
在InnoDB中，锁可以分为两种级别，一种是共享锁（S锁），另一种是排他锁（X锁）。
但是，实际上「插入意向锁」不是意向锁，而是特殊的间隙锁，属于行级锁，注意是「特殊」的间隙锁，并不是我们常说的间隙锁。
InnoDB实现标准的行级锁定，其中有两种类型的锁： 共享（S）锁和排他（X）锁。
MySQL在RR隔离级别下引入间隙锁来解决数据记录的幻读问题，在RC隔离级别下，通常间隙锁会消失，降级为记录锁，所以在RC隔离级别下能够提高并发写入的性能。
疫情期间在家工作时，同事使用了 insert into on duplicate key update 语句进行插入去重，但是在测试过程中发生了死锁现象:
Linux进程间通信 Ø 管道与消息队列 ü 匿名管道，命名管道 ü 消息队列 Ø 信号 ü 信号基础 ü 信号应用 Ø 锁与信号灯 ü 记录锁 ü 有名信号灯 ü 无名信号灯（基于内存的信号灯） Ø
数据库的锁是为了解决事务的隔离性问题，为了让事务之间相互不影响，每个事务进行操作的时候都会对数据加上一把特有的锁，防止其他事务同时操作数据。如果你想一个人静一静，不被别人打扰，那么请在你的房门上加上一把锁。
表锁是MySQL中最基本的锁策略，并且是开销最小的策略。表锁会锁定整张数据表，用户的写操作（插入/删除/更新）前，都需要获取写锁（写锁会相互阻塞）；没有写锁时，读取用户才能获取读锁（读锁不会相互阻塞）。
松哥最近正在录制 TienChin 项目视频～采用 Spring Boot+Vue3 技术栈，里边会涉及到各种好玩的技术，小伙伴们来和松哥一起做一个完成率超 90% 的项目，戳戳戳这里-->TienChin 项目配套视频来啦。
疫情期间在家工作时，同事使用了 insert into on duplicate key update 语句进行插入去重，但是在测试过程中发现了死锁现象:
这时候可以用 select*frominformation_schema.innodb_locks;查看锁情况：
这时候可以用select * from information_schema.innodb_locks;查看锁情况：
往期在文章《介绍Innodb的锁机制》中提到过关于记录锁，但是没有详细展开描述。本片文章简单聊一聊。
有一道关于「数据库锁」的面试题。我们发现其实很多 DBA （数据库管理员，Database administrator）包括工作好几年的 DBA 都答得不太好。这说明 MySQL 锁的机制其实还是比较复杂，值得深入研究。本文对3条简单的查询语句加锁情况进行分析，以期帮助各位开发者彻底搞清楚加锁细节。欢迎阅读~
锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中数据其实是一种供大量用户共享的资源，所以在并发访问时我们需要保证数据的一致性和有效性，而锁冲突是影响数据库并发性能最关键的因素之一。所以本篇文章主要讨论Mysql中锁机制的特点。Mysql的锁机制包含多种：行锁，表锁，读锁，写锁等，其实就是使用不同的存储引擎会支持不同的锁机制。而我主要是针对InnoDB存储引擎下的7种类型的锁进行介绍。
大概就是，在线上执行一条 update 语句修改数据库数据的时候，where 条件没有带上索引，导致业务直接崩了，被老板教训了一波
InnoDB默认的事务隔离级别是repeatable read（后文中用简称RR），它为了解决该隔离级别下的幻读的并发问题，提出了LBCC（锁机制）和多版本并发控制（MVCC）两种方案。其中LBCC解决的是当前读情况下的幻读，MVCC解决的是普通读（快照读）的幻读。
MySQL中的间隙是指索引中两个索引键之间的空间，间隙锁用于防止范围查询期间的幻读，确保查询结果的一致性和并发安全性。
这段时间一直在学习MySQL数据库。项目组一直用的是Oracle，所以对MySQL的了解也不深。本文主要是对MySQL锁的总结。
有一定编程基础的小伙伴应该都接触过文件编程吧，file. 在C语言里面是包一个<file.h>的头
前文提到，对于 InnoDB 来说，随时都可以加锁（关于加锁的 SQL 语句这里就不说了，忘记的小伙伴可以翻一下上篇文章），但是并非随时都可以解锁。具体来说，InnoDB 采用的是两阶段锁定协议（two-phase locking protocol）：即在事务执行过程中，随时都可以执行加锁操作，但是只有在事务执行 COMMIT 或者 ROLLBACK 的时候才会释放锁，并且所有的锁是在同一时刻被释放。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
