- 当前位置：首页 >应用开发 >MySQL那些“锁”事，你听烦了吗？
MySQL那些“锁”事，你听烦了吗？
发布时间：2025-11-05 03:17:25 来源：技术快报 作者：系统运维
MySQL锁介绍
根据加锁的锁范围，MySQL 里面的事听锁大致可以分成全局锁、表级锁、锁行锁三类。事听
图片
全局锁
顾名思义，锁全局锁就是事听对整个数据库实例加锁。MySQL 提供了一个加全局读锁的锁方法，命令是事听 Flush tables with read lock (FTWRL)。当你需要让整个库处于只读状态的锁时候，可以使用这个命令，事听之后其他线程的锁以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、事听修改表结构等）和更新类事务的锁提交语句。全局锁的事听典型使用场景是，做全库逻辑备份。锁也就是把整库每个表都 select 出来存成文本。
官方自带的逻辑备份工具是 mysqldump。当 mysqldump 使用参数–single-transaction 的时候，导数据之前就会启动一个事务，站群服务器来确保拿到一致性视图。而由于 MVCC 的支持，这个过程中数据是可以正常更新的。
一致性读是好，但前提是引擎要支持这个隔离级别。比如，对于 MyISAM 这种不支持事务的引擎，如果备份过程中有更新，总是只能取到最新的数据，那么就破坏了备份的一致性。这时，我们就需要使用 FTWRL 命令了。
表锁
元数据锁
元数据锁，即MDL全称为mysql metadata lock，当表有活动事务的时候，不可以对元数据进行写入操作。所以说MDL作用是维护表元数据的数据一致性
MDL的作用是确保并发事务之间对数据库对象的操作不会互相冲突或产生不一致的结果。b2b信息网当一个事务对某个数据库对象执行了锁定操作时，其他事务对同一对象的锁请求会被阻塞，直到持有锁的事务释放锁。
以下是MDL的一些特点和使用场景：
1. 读-写冲突：MDL具有读-写冲突，即一个事务持有写锁时会阻塞其他事务的读和写操作。这确保了在写操作进行期间，其他事务无法读取或修改受锁保护的对象。2. 写-写冲突：MDL还存在写-写冲突，即一个事务持有写锁时会阻塞其他事务的写操作。这保证了同一时间只能有一个事务对一个对象进行写操作，避免了并发写操作引起的数据不一致问题。3. 共享读锁：MDL允许多个事务同时获取读锁，因为读操作之间不会相互冲突。4. 锁的级别：MDL的锁级别是语句级别的，而不是表级别或行级别的。这意味着对于同一表的不同语句，可以同时持有读锁和写锁，因为它们不会互相冲突。网站模板自增锁Auto-inc Locks
是特殊的表级别锁，专门针对事务插入AUTO_INCREMENT类型的列。
原理：每张表自增长值并不保存在磁盘上进行持久化，而是每次InnoDB存储引擎启动时，执行以下操作：
复制SELECT MAX(auto_inc_col) FROM T FOR UPDATE;1.之后得到的值会用变量auto_inc_lock作缓存，插入操作会根据这个自增长值加1赋予自增长列。因为每张表只有同一时刻只能有一个自增锁，可以避免同一表锁对象在各个事务中不断地被申请。
为了提高插入的性能，在MySQL5.1版本之后，对于普通的insert语句，自增锁每次申请完马上释放，不是在一个事务完成后才释放，以便允许别的事务再次申请。
举个例子：假设Test表有主键id和唯一索引列a，有两个并行事务A和B，为了避免两个事务申请到相同的主键id，必须要加自增锁顺序申请
事务A
事务B
begin;
insert into Test values(null,1);
begin;
insert into Test values(null,2);
commit;
//插入的行(2,2)
commit;
事务A申请到主键id=1之后释放自增锁，没有等事务A提交之后释放，所以事务B可以插入不被阻塞。
什么情况自增主键不是连续的呢？
• 事务回滚，如果在事务中插入了带有自增主键的记录，但该事务最终被回滚（rollback），则该自增值将被释放，不会被后续事务使用。这可能导致自增主键出现间隔或不连续的情况。• 手动插入了自增主键的值，而不是使用系统自动生成的自增值，可能会导致自增主键的连续性中断。例如，使用INSERT语句指定了特定的自增主键值。• 特殊的批量插入语句insert...select。表级共享与排他锁
• 表级共享锁,又称为表共享读锁，既在表的层级上对数据加以共享锁，实现读读共享• 表级排他锁,又称为表独占写锁，既在表的层级上对数据加以排他锁，实现读写互斥，写写互斥表级意向锁
表级意向锁（Table-level Intention Lock）是MySQL中一种用于管理表级锁的机制。它是一种轻量级的锁，用于指示事务对表的意向操作，即事务打算在表级别上执行读操作或写操作。
表级意向锁分为两种类型：
1. 意向共享锁（Intention Shared Lock，IS）：事务打算在表级别上执行读操作时，会申请意向共享锁。意向共享锁不会阻止其他事务获取表级共享锁或意向共享锁，但会阻止事务获取表级排他锁。2. 意向排他锁（Intention Exclusive Lock，IX）：事务打算在表级别上执行写操作时，会申请意向排他锁。意向排他锁会阻止其他事务获取表级共享锁、意向共享锁或意向排他锁。表级意向锁的作用是协调并发事务对表的锁定操作，以确保数据一致性和避免死锁。事务在对表进行锁定操作之前，首先获取意向锁，并根据需要再获取具体的行级锁。它们存在的目的是帮助其他事务确定是否可以安全地获取表级共享锁或排他锁，以避免冲突和死锁的发生。
行锁
行级共享与排他锁
因为InnoDB支持表锁和行锁。所以在数据库层次结构的表级和行级，都可以对数据进行锁定。
• 行级共享锁,行级共享锁既在行的层级上，对数据加以共享锁，实现对该行数据的读读共享• 行级排他锁,行级排他锁既在行的层级上，对数据加以排他锁，实现对该行数据的读写互斥，写写互斥显式地加共享锁或排他锁？• select * from table lock in share mode 为table的所有数据加上共享锁，既表级共享锁• select * from table for update 为table的所有数据加上排他锁，既表级排他锁• select * from table where id = 1 for update 为table中id为1的那行数据加上排他锁，既行级排他锁• select * from table where id = 1 lock in share mode为table中id为1的那行数据加上共享锁，既行级共享锁以上加的是行锁的前提是，id为主键且在查询命中，否则行锁会升级为表锁。共享锁之间兼容，排它锁与任何锁都不兼容
自增锁、意向锁和行级锁的兼容性
自增锁、意向锁和行级锁的兼容性如下：
AI
IS
IX
S
X
AI
不兼容
兼容
兼容
不兼容
不兼容
IS
兼容
兼容
兼容
兼容
不兼容
IX
兼容
兼容
兼容
不兼容
不兼容
S
不兼容
兼容
不兼容
兼容
不兼容
X
不兼容
不兼容
不兼容
不兼容
不兼容
意向锁是一个比较弱的锁，所以意向锁之间互不排斥
InnoDB锁算法
记录锁Record Locks单个行记录上的锁，用来封锁索引记录。
如：假设Test表有主键id和唯一索引列a，已经有了(1,1)这条记录，执行
复制select * from Test where id=1 for update；1.会在id=1的索引记录上加锁，以阻止其他事物插入更新、删除id=1这一行。
间隙锁Gap Locks间隙锁（Gap Lock），它会封锁索引记录中的“缝隙”，不让其他事务在“缝隙”中插入数据。它锁定的是一个不包含索引本身的开区间范围 (index1,index2)。间隙锁是封锁索引记录之间的间隙，或者封锁第一条索引记录之前的范围，又或者最后一条索引记录之后的范围.锁定一个范围，但不包含记录本身。
封锁索引记录中的间隙，确保索引记录的间隙不变。间隙锁是针对事务隔离级别为可重复读(RR)或以上级别而已的，如果隔离级别降级为读提交(RC)，间隙锁会自动失效。
MySQL事务实现原理中我们了解到幻读是指一个事务在前后两次查询同一个范围的时候，后一次查询看到了前一次查询没看到的行，具体例子如下：
复制CREATE TABLE `t1` ( `id` int(11) NOT NULL, `a` int(11) DEFAULT NULL, `b` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `a` (`a`) ) ENGINE=InnoDB; insert into t values(0,0,5),(5,5,5),(10,10,5);1.2.3.4.5.6.7.8.如果只在 id=5 这一行加锁，而其他行的不加锁的话，就会发生以下情况
事务A
事务B
事务C
begin;
select * from t1 where a=5 for update;
/Q1/result:(5,5,5)
update t1 set a=5 where id=0;
select * from t1 where a=5 for update;
/Q2/result:(0,5,5)(5,5,5)
inset into t1 values(1,5,5);
select * from t1 where a=5 for update;
/Q3/result:(0,5,5)(1,5,5)(5,5,5)
commit;
Q3读到了id=1这一行，就叫“幻读”。
如何解决幻读？
比如继续使用上面例子的表，执行select * from t1 where b=5 for update时候，由于b没有索引，就会在插入3个记录锁，和4个间隙锁，这样就确保了无法再插入新的记录，以此防止幻读的发生，如下：
复制(-∞,0),(0,5),(5,10),(10,+∞)1.间隙锁在往间隙中插入一个记录才会冲突，间隙锁之间不存在冲突关系。
临键锁Next-key Locks临键锁是记录锁与间隙锁的组合。
为了避免幻读，当InnoDB扫描索引记录的时候，会首先对索引记录加上行锁（Record Lock），再对索引记录两边的间隙加上间隙锁（Gap Lock）
innodb只有在RR隔离级别下、并且参数innodb_locks_unsafe_for_binlog关闭下，才有通过next-key locks来避免幻读。
如果是RC隔离级别，间隙锁就会失效，只剩下行锁部分，而且对于语句执行过程也有优化，使得锁的范围也会更小，时间更短，不容易死锁。
插入意向锁Insert Intention Locks是间隙锁的一种，专门针对insert操作。同一个索引，同一个范围区间插入记录，插入的位置不冲突，不会阻塞彼此，可以提高插入并发。
由于插入意向锁和其他的临建锁/间隙锁本身会冲突，下面的两个事务会冲突：
图片
插入意向锁经常和间隙锁引发死锁问题，死锁是指两个或者多个事务在同一资源上相互占用，并请求锁定对方占用的资源，从而导致恶性循环的现象。
简单模拟一个死锁的场景：
事务A
事务B
begin;
update t1 set a=a+1 where id=1;
begin;
update t1 set a=a+1 where id=2;
update t1 set a=a+1 where id=2;
update t1 set a=a+1 where id=1;
事务A在等待事务B释放id=2的行锁，事务B在等待A释放id=1的行锁，事务A和事务B互相等待对方释放资源，于是进入了死锁状态。
插入不会主动加显示的X Record锁，只有检测到Key冲突的时候才会把隐式锁转为显式锁。
隐式锁你可以理解为乐观锁，也就是正常来说不加锁或共享锁，但是遇到冲突则加锁或升级为排它锁。显式锁，那就是真的锁上了。
MySQL加锁规则
林晓斌总结MySQL加锁规则：包含了两个“原则”、两个“优化”和一个“bug”。
• 原则 1：加锁的基本单位是 next-key lock。next-key lock 是前开后闭区间。
• 原则 2：查找过程中访问到的对象才会加锁。
• 优化 1：索引上的等值查询，给唯一索引加锁的时候，next-key lock 退化为行锁。
• 优化 2：索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁。
• 一个 bug：唯一索引上的范围查询会访问到不满足条件的第一个值为止。
下面我们通过例子看一下这些规则：我们建个表，插入一些初始化数据：
复制CREATE TABLE `t` ( `id` int(11) NOT NULL, `c` int(11) DEFAULT NULL, `d` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `c` (`c`) ) ENGINE=InnoDB; insert into t values(0,0,0),(5,5,5),(10,10,10),(15,15,15),(20,20,20),(25,25,25);1.2.3.4.5.6.7.8. 等值查询间隙锁
由于表 t 中没有 id=7 的记录，所以用我们上面提到的加锁规则判断一下的话：
1. 根据原则 1，加锁单位是 next-key lock，session A 加锁范围就是 (5,10]；
2. 同时根据优化 2，这是一个等值查询 (id=7)，而 id=10 不满足查询条件，next-key lock 退化成间隙锁，因此最终加锁的范围是 (5,10)。
所以，session B 要往这个间隙里面插入 id=8 的记录会被锁住，但是 session C 修改 id=10 这行是可以的。
非唯一索引等值锁
image.png
这里 session A 要给索引 c 上 c=5 的这一行加上读锁。
1. 根据原则 1，加锁单位是 next-key lock，因此会给 (0,5]加上 next-key lock。要注意 c 是普通索引，因此仅访问 c=5 这一条记录是不能马上停下来的，需要向右遍历，查到 c=10 才放弃。
2. 根据原则 2，访问到的都要加锁，因此要给 (5,10]加 next-key lock。
3. 但是同时这个符合优化 2：等值判断，向右遍历，最后一个值不满足 c=5 这个等值条件，因此退化成间隙锁 (5,10)。
4. 根据原则 2 ，只有访问到的对象才会加锁，这个查询使用覆盖索引，并不需要访问主键索引，所以主键索引上没有加任何锁，这就是为什么 session B 的 update 语句可以执行完成。
但 session C 要插入一个 (7,7,7) 的记录，就会被 session A 的间隙锁 (5,10) 锁住。需要注意，在这个例子中，lock in share mode 只锁覆盖索引，但是如果是 for update 就不一样了。执行 for update 时，系统会认为你接下来要更新数据，因此会顺便给主键索引上满足条件的行加上行锁。
主键索引范围锁举例之前，我们先思考一下这个问题：对于我们这个表 t，下面这两条查询语句，加锁范围相同吗？
复制select * from t where id=10 for update; select * from t where id>=10 and id<11 for update;1.2.你可能会想，id 定义为 int 类型，这两个语句就是等价的吧？其实，它们并不完全等价。在逻辑上，这两条查语句肯定是等价的，但是它们的加锁规则不太一样。现在，我们就让 session A 执行第二个查询语句，来看看加锁效果。
图片
现在我们就用前面提到的加锁规则，来分析一下 session A 会加什么锁呢？
1. 开始执行的时候，要找到第一个 id=10 的行，因此本该是 next-key lock(5,10]。根据优化 1， 主键 id 上的等值条件，退化成行锁，只加了 id=10 这一行的行锁。
2. 范围查找就往后继续找，找到 id=15 这一行停下来，因此需要加 next-key lock(10,15]。
所以，session A 这时候锁的范围就是主键索引上，行锁 id=10 和 next-key lock(10,15]。
这里需要注意一点，首次 session A 定位查找 id=10 的行的时候，是当做等值查询来判断的，而向右扫描到 id=15 的时候，用的是范围查询判断。
非唯一索引范围锁需要注意的是，与主键范围锁不同的是，下面查询语句的 where 部分用的是字段 c。
图片
这次 session A 用字段 c 来判断，加锁规则不同是：在第一次用 c=10 定位记录的时候，索引 c 上加了 (5,10]这个 next-key lock 后，由于索引 c 是非唯一索引，没有优化规则，也就是说不会蜕变为行锁，因此最终 sesion A 加的锁是，索引 c 上的 (5,10] 和 (10,15] 这两个 next-key lock。
所以从结果上来看，sesson B 要插入（8,8,8) 的这个 insert 语句时就被堵住了。这里需要扫描到 c=15 才停止扫描，是合理的，因为 InnoDB 要扫到 c=15，才知道不需要继续往后找了。
唯一索引范围锁 bug接下来再看一个关于加锁规则中 bug 的案例
图片
session A 是一个范围查询，按照原则 1 的话，应该是索引 id 上只加 (10,15]这个 next-key lock，并且因为 id 是唯一键，所以循环判断到 id=15 这一行就应该停止了。但是实际上，InnoDB 会往前扫描到第一个不满足条件的行为止，也就是 id=20。而且由于这是个范围扫描，因此索引 id 上的 (15,20]这个 next-key lock 也会被锁上。所以我们看到了，session B 要更新 id=20 这一行，是会被锁住的。同样地，session C 要插入 id=16 的一行，也会被锁住。照理说，这里锁住 id=20 这一行的行为，其实是没有必要的。因为扫描到 id=15，就可以确定不用往后再找了。但实际上还是这么做了，因此认为这是个 bug。
非唯一索引上存在"等值"的例子插入一条数据
复制insert into t values(30,10,30);1.新插入的这一行 c=10，也就是说现在表里有两个 c=10 的行。那么，这时候索引 c 上的间隙是什么状态了呢？由于非唯一索引上包含主键的值，所以是不可能存在“相同”的两行的。
图片
可以看到，虽然有两个 c=10，但是它们的主键值 id 是不同的（分别是 10 和 30），因此这两个 c=10 的记录之间，也是有间隙的。
图中索引 c 上的主键 id。为了跟间隙锁的开区间形式进行区别，用 (c=10,id=30) 这样的形式，来表示索引上的一行。
图片
这时，session A 在遍历的时候，先访问第一个 c=10 的记录。
1. 同样地，根据原则 1，这里加的是 (c=5,id=5) 到 (c=10,id=10) 这个 next-key lock。然后，session A 向右查找，直到碰到 (c=15,id=15) 这一行，循环才结束。2. 根据优化 2，这是一个等值查询，向右查找到了不满足条件的行，所以会退化成 (c=10,id=10) 到 (c=15,id=15) 的间隙锁。也就是说，这个 delete 语句在索引 c 上的加锁范围，就是下图中蓝色区域覆盖的部分。
图片
这个例子里，session A 的 delete 语句加了 limit 2。你知道表 t 里 c=10 的记录其实只有两条，因此加不加 limit 2，删除的效果都是一样的，但是加锁的效果却不同。可以看到，session B 的 insert 语句执行通过了，跟案例六的结果不同。这是因为，案例七里的 delete 语句明确加了 limit 2 的限制，因此在遍历到 (c=10, id=30) 这一行之后，满足条件的语句已经有两条，循环就结束了。因此，索引 c 上的加锁范围就变成了从（c=5,id=5) 到（c=10,id=30) 这个前开后闭区间，如下图所示：
图片
可以看到，(c=10,id=30）之后的这个间隙并没有在加锁范围里，因此 insert 语句插入 c=12 是可以执行成功的。这个例子对我们实践的指导意义就是，在删除数据的时候尽量加 limit。这样不仅可以控制删除数据的条数，让操作更安全，还可以减小加锁的范围。
一个死锁的例子next-key lock 实际上是间隙锁和行锁加起来的结果。
图片
现在，我们按时间顺序来分析一下为什么是这样的结果。
1. session A 启动事务后执行查询语句加 lock in share mode，在索引 c 上加了 next-key lock(5,10] 和间隙锁 (10,15)；
2. session B 的 update 语句也要再索引 c 上加 next-key lock(5,10] ，进入锁等待；
3. 然后 session A 要再插入 (8,8,8) 这一行，被 session B 的间隙锁锁住。由于出现了死锁，InnoDB 让 session B 回滚。
你可能会问，session B 的 next-key lock 不是还没申请成功吗？其实是这样的，session B 的“加 next-key lock(5,10] ”操作，实际上分成了两步，先是加 (5,10) 的间隙锁，加锁成功；然后加 c=10 的行锁，这时候才被锁住的。
也就是说，我们在分析加锁规则的时候可以用 next-key lock 来分析。但是要知道，具体执行的时候，是要分成间隙锁和行锁两段来执行的。
避免死锁有哪些方法？
• 以固定的顺序访问表和行。
• 大事务拆小。大事务更容易发生死锁，如果业务允许，将大事务拆小。
• 在同一个事务中，尽可能做到一次锁定所需要的所有资源，减少死锁概率。
• 降低隔离级别。如果业务允许，将隔离级别调低也是较好的选择，比如将隔离级别从RR调整为RC，可以避免掉很多因为gap锁造成的死锁。
• 为表添加合理的索引。
- 如何以3分钟强制删除管理员权限文件（快速、高效、安全的解决办法）
- 宜信P2P投资平台的优势与风险（深入剖析宜信P2P的投资机会和潜在风险）
- 飞利浦SA5208耳机（探索SA5208耳机的出色音质和舒适设计）
- 戴尔3320笔记本电脑的性能和特点剖析（优秀性能、轻便设计、高效工作的首选）
- USP无线网卡安装教程（详细指南帮助您轻松安装和使用USP无线网卡）
- 漫步者K800耳机（探索音乐新境界，尽在K800耳机）
- 罗马仕Sense4（一款高性能、便携的智能充电宝，为您的生活带来便利与乐趣）
- 以海欧电商（打造全球化、智能化、可持续发展的跨境电商平台）
- 技嘉主板H61MS1——性能稳定可靠的选择（技嘉主板H61MS1的特点与优势）
- 盘石主板（稳定可靠、超频潜力大、适应多种用途）
- 免费的电脑视频剪辑软件推荐（享受高质量视频剪辑体验，尽在免费软件中）
- 高通骁龙600（探究骁龙600系列处理器的性能特点及优势）
- 以盖茨机滤的性能和效果如何？（了解以盖茨机滤的过滤效能与优点）
- 以92回收（让废弃物转为财富，共创绿色未来）
- 如何更换旧电脑的网卡（简单易懂的教程，轻松升级你的网络连接）
- 缤果交友，缔造真挚友谊（探索新的社交方式，让缘分聚焦于心灵契合）
- 卓威键盘（一键通畅，打字如行云流水）
- 淫秽内容对人的心理健康的影响（探索淫秽对人类心理的冲击与后果）
- 掌握平板电脑4指操作技巧，高效利用设备（简单易学的平板电脑4指操作教程，助您成为高手）
- U2417H显示器的游戏体验如何？（探索U2417H显示器游戏性能的优缺点）
随便看看
- Copyright © 2025 Powered by MySQL那些“锁”事，你听烦了吗？,技术快报 滇ICP备2023006006号-46sitemap