聊聊MySQL中的锁

关注

原创最新推荐文章于 2026-05-11 12:19:52 发布 515 阅读 AI 写同款· GEO 优化 ›

从电商秒杀到文件上传：聊聊upload-labs第17关背后的‘条件竞争’与MySQL锁的妙用本文深入探讨了条件竞争漏洞在文件上传和电商秒杀等场景中的危害，并以upload-labs第17关为例，详细解析了漏洞原理及防御策略。重点介绍了MySQL悲观锁与乐观锁的实战应用，以及分布式环境下的锁机制演进，为开发者提供了多层防御体系构建方案。阅读详情

原文地址：http://www.linzichen.cn/article/1571531799593484288

在程序开发中，当多个线程并发操作共享数据时，我们需要保证在任何时刻最多只能有一个线程在操作，以保证数据的 完整性和一致性。比如在 JAVA 中，单体应用有 synchornized 和 ReentrantLock锁，分布式应用有 分布式锁。同样在数据库中，用户数据作为一种共享资源，同样也提供对应的锁机制。

一、多事务访问的几种情况

并发事务访问相同记录的情况大致可以分为三种：

读读、写写、读写或写读。

1.1 读 - 读

即并发事务相继读取相同的记录。读取操作不会对记录有任何影响，也不会引起什么问题，所以允许这种情况发生。

1.2 写 - 写

即并发事务相继对相同的记录做出改动。

在这种情况下会发生脏写的问题，所以在多个事务对一条记录做改动时，需要让它们 排队执行。排队过程就是通过锁来实现的。它们的流程为：

1、当事务 T1 想对记录改动时，会先判断内存中是否存在当前记录的锁。如果不存在，则 T1会在内存中生成一个锁结构，与当前记录关联。
锁结构.png

锁结构中有很多信息，其中有两个重要的属性：

trx信息：当前锁结构是哪个事务生成的。
is_waiting：当前事务是否是等待状态。

2、在 T1事务提交之前，另一个事务T2也要对当前记录做改动，但是此时内存中，还存在 T1事务的锁与当前记录关联，所以 T2也会生成一条与当前记录关联的锁结构，只不过 T2锁结构的 is_waiting属性值是 true，代表当前事务需要等待。

3、在事务 T1提交之后，就会把它生成的锁结构释放掉，然后看看内存中有没有别的事务锁在等待状态，发现 T2在等待之后，会把 T2对应的锁结构的 is_waiting属性改为 false，然后把该事务的线程唤醒，让它继续执行，此时事务 T2就算获取到锁了，可以继续执行。

脏写：一个事务修改了另一个事务未提交的数据。
比如事务T1进行了 insert但还未提交：
insert into t1 (id, name) values (1, '张三');
但事务 T2对 T1未提交的数据进行了修改：
update t1 set name = '李四' where id = 1;
如果T1进行了回滚，那此数据实际是不存在的。这种现象就是脏写，数据库中任何隔离级别都不允许此情况发生。

1.3 读 - 写或写 - 读

即一个事务进行读操作，另一个进行写操作。这种情况下可能发生 脏读、不可重复读、幻读的问题。

脏读：事务T1读了另一个事务T2还未提交的数据。比如 T2进行了insert但还未提交，此时 T1事务select到了此数据，这种现象就是脏读。
不可重复读：事务T1查询了id=1的记录的name字段是张三，此时事务T2对此记录的name改为了 李四，并且提交了。然后 T1再次查询时发现 name字段变成了 李四。前后读取的数据不一致，这种现象就是不可重复读。
幻读：事务 T1查询了表中id>1的记录有3条，此时事务 T2进行了 insert操作（id > 1）并且提交，然后T1再次查询时记录变成了 4条。前后读取的记录数不一致。这种现象就是幻读。

二、并发事务问题解决方案

为了解决 脏读、不可重复读和幻读 这些现象的发生，其实有两种可选的解决方法。

MVCC

读操作利用 MVCC，写操作加锁。

所谓MVCC，就是通过 undo日志的版本链和 ReadView快照构成的多版本并发控制，它实际读取的是版本链中最新提交的数据，而非其他活动事务正在操作的数据，这样就可以避免因为活动中事务的写，造成的一系列的问题。MVCC不是本文的重点内容，所以这里不做过多介绍了。

加锁

脏读是因为事务 T1读到了事务T2写入的未提交的数据。那我们只要在T2写的时候加锁，让T1读的时候等待，等T2提交后才允许读，就可以避免脏读现象。

不可重复读是因为事务 T1先读了一条记录，随后事务T2修改了当前记录并提交，等T1再读时发现跟第一次读的不一致了。那我们只要在T1读的时候加锁，让T2写的时候等待，等T1读完之后T2再去进行写操作，就可以避免不可重复读。

幻读是因为事务T1查询了一个范围内的记录，随后事务T2对当前范围内插入了新的记录并提交，导致T1再查询范围时发现记录数变了。那我们可以在T1查询的范围上给加锁，此时T2在此范围内插入数据时让其等待，就可以避免幻读。

三、锁从不同角度的分类

mysql中的锁，不但保证了数据的一致性，而且还为实现各个隔离级别提供了保证。尤其对于一些敏感数据上我们必须采用加锁的方式，所以锁对数据库而言显得尤其重要，也更加复杂。本文从mysq锁的不同角度，详细聊一聊mysql中的锁。

锁家族.jpg

四、操作角度：读写锁

对于数据库中并发事务的读-读不会引起什么问题。对于 写-写、读-写或写-读这些情况可能会引起一些问题，需要通过 MVCC或加锁方式解决。在使用加锁方式时，由于既要允许读-读情况不受影响，又要使 写-写、读-写或写-读情况中的操作互相阻塞，所以mysql实现一个由两种类型的锁组成的锁系统来解决。这两种类型的锁通常被称为共享锁（Shared Lock）和排他锁（Excluslve Lock），也叫读锁（read lock）和写锁（write lock）。

4.1 共享锁

也称为读锁，英文用 S表示。针对同一份数据，多个事务的共享锁可以同时进行而不互相影响，互相不阻塞。

4.2 排他锁

也成为写锁，英文用 X表示。此事务没有完成前，它会阻断其他的排他锁和共享锁。这样能确保在给定的时间里，有且只有一个事务能访问同一资源。

4.3 读锁案例

对读的记录加S锁：

一般情况下，我们需要对读操作加S锁，以避免不可重复读、幻读这些问题。

select …… lock in share moe;
# 或
select …… for share; #（8.0语法）

在普通的select语句后面加 lock in share mode，如果当前事务执行了该语句，那么它会为读取到的记录加S锁，此时允许其他事务继续获取这些记录的S锁，但是不能获取这些记录的X锁。想获取X锁的事务将会阻塞，知道当前事务的S锁释放掉后才可以。

读-读：
读读.png

读-写：
读写.png

4.4 写锁案例

对读取记录加X锁：

在有些场景下，比如涉及到金额存取款问题等，我们需要对读操作加X锁。即当前事务在读取的时候，不需要其他的事务进行读写操作。

select …… for update;

在普通的select语句后加for update，如果当前事务执行了该语句，那么事务会为读取的记录加X锁。此时其他事物，无论是对这些记录加S锁 还是 X锁，都会进入阻塞状态。

写-读：
写读.png

写-写：
写写.png

4.5 小结：

当一个事务加了S锁，其他事务S锁不影响，X锁阻塞。

当一个事务加了X锁，其他事务S锁阻塞，X锁阻塞。

	S锁	X锁
S锁	不阻塞	阻塞
X锁	阻塞	阻塞

在5.7及之前版本，select …… for update，如果获取不到锁，会一直等待，直到innodb_lock_wait_timeout超时。
在8.0版本中，select …… for update，select …… for share 添加 NOWAIT、SKIP LOCKED语法，可以跳过锁等待，或者跳过锁定。

如果查询的行已经加锁：

NOWAIT：会立即返回报错。
SKIP LOCKED：会立即返回结果，结果中不包含被锁定的行。

五、数据操作粒度角度：表锁、页锁、行锁

为了尽可能提高数据库的并发度，每次锁定的数据范围越小越好，理论上每次只锁定当前操作的数据会得到最大的并发度，但是管理锁是很耗资源的事情（涉及获取、检查、释放锁等动作）。因此数据库系统需要在高并发响应 和 系统性能两方面进行平衡，就产生了 锁粒度的概念。

对一条记录加锁影响的就是该记录而已，我们就说这个锁的粒度比较细；一个事务也可以在表级别进行加锁，我们称之为 表锁，对一个表加锁会影响这个表的记录，我们就说这个锁的粒度比较粗。锁的粒度主要分为表锁、页锁和行锁。

5.1 表锁

5.1.1 表级别的读写锁

在对表执行select、insert、delete、update 这些DML语句时，InnoDB不会为该表添加 S锁或X锁的，但是其他事务对该表进行 alter table、drop table 等这类 DDL语句时会发生阻塞。同理，当事务对表进行 DDL时，其他事务的 DML也会进行堵塞。这个过程是通过在server层使用一种称之为元数据锁（Metadata Locks，简称 MDL）结构来实现的。

表锁.png

手动获取表的 S锁或者X锁：

lock tables t read：对表 t加 S锁。
lock tables t write：对表 t加 X锁。
lock tables t1 read, t2 write;：对表t1加S锁，t2加写锁。

表S锁.png

查看正在加锁的表：

show open tables where In_use > 0;

释放当前会话的读写锁：

unlock tables：只能释放当前会话的锁，其他会话的锁释放不了。

小结

关于表锁的读写类型，可以用下面表格来概述：

锁类型	自己可读	自己可写	自己可操作其他表	他人可读	他人可写
读锁	是	否	否	是	否，等
写锁	是	是	否	否，等	否，等

一般情况下不会对InnoDB存储引擎使用表级别的 S锁和X锁，它们并不会提供什么额外的保护，只会降低并发能力而已。InnoDB的厉害之处是实现了更细粒度的 行锁。

5.1.2 表级别的意向锁

概念

意向锁是由存储引擎自己维护的一种表级锁，我们自己无法手动操作意向锁。当我们给表中的某些记录添加了 共享锁时，存储引擎会自动给所在的表添加 意向共享锁；当我们给表中的某些记录添加了排他锁时，存储引擎会自动给所在的表添加意向排他锁。

意向共享锁（intention shared lock，IS）：由事务添加行的共享锁时，存储引擎自动给表添加的。
意向排他锁（intention exclusive lock，IX）：由事务添加行的排他锁时，存储引擎自动给表添加的。

为什么需要意向锁

此时可能会有疑问，我们既然给表中的记录填加行级的共享/排他锁，为什么还需要给表添加意向锁？其实意向锁的存在，是为了协调行锁和表锁的关系。举个例子：

假如事务T1想给a表添加表的排他锁（X锁），因为排他锁互斥的关系，T1需要在加锁前，判断该表中的所有记录行，是否存在 S锁 或 X锁，如果数据量很大，每一行都去做判断则非常的耗时。所以我们在给表中记录添加S/X锁时，会对应的给表也添加上IS/IX锁。此时事务T1再想给表a添加X锁时，只需要先判断该表是否存在 IS/IX锁即可，就不需要再去遍历每一行判断了，可以提升系统效率。

意向锁之间的关系

行级锁的某一条记录，同一时间内可以存在多个S锁，但只能存在一个X锁，且S锁与X锁互相排斥。而在意向锁中，由于多个事务可以给记录同时添加S锁，所以一个表也会存在多个IS锁；由于多个事务可以给表中不同的记录分别添加X锁，所以一个表也会存在多个IX锁。

所以我们得出结论，意向锁之间互不排斥，可以共存。意向锁与行锁之间不排斥，可以共存。

表锁与意向锁之间：表的S锁与 IS锁可以共存，其余的表锁与意向锁互斥。

小结

InnoDB支持多粒度锁，行级锁可以与表级锁共存。
意向锁之间互相兼容，意向锁与行级锁之间互相兼容。
意向共享锁与表共享锁兼容，其余的意向锁与表锁互不兼容。
意向锁在保证并发的前提下，实现了行锁和表锁共存且满足事务隔离性的要求。

5.1.3 表级别的元数据锁

mysql5.5 引入了 meta data lock，简称MDL锁，属于表锁范畴。MDL的作用是，保证读写的正确性。比如如果一个查询正在遍历表中的数据，而执行期间另一个线程对这个表结构做变更，增加了一个字段，那么查询线程拿到的结果跟表结构对不上，肯定不允许的。

因此，当对一个表做增删改查操作的时候，加MDL读锁；当对表做结构变更操作的时候，加MDL写锁。

读锁之间不互斥，因此可以有多个线程同时对一张表增删改查。读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性，解决了DML和DDL操作之间的一致性问题。不需要显示调用，在访问一个表的时候会自动加上。

元数据锁.png

此时返现DDL操作的事务处于等待状态，看一下当前正在运行的线程，发现该事务正在进行元数据锁等待。

元数据锁等待.png

5.2 InnoDB行锁

行锁（Row Lock）也称为记录锁，顾名思义，就是锁住某一行（某条记录）。需要注意的是，mysql 服务层并没有实现行锁机制，行级锁只在存储引擎层实现。

优点：锁定粒度小，发生 锁冲突概率低，可以实现的 并发度搞。

缺点：对于锁的开销比较大，加锁会比较慢，容易出现死锁情况。

InnoDB与MyISAM最大不同有两点：一是支持事务；二是采用了行级锁。

5.2.1 记录锁

记录锁是有S锁和X锁之分的，称之为S型记录锁和X型记录锁。

当一个事务获取了一条记录的S型记录锁后，其他事务也可以继续获取该记录的S型记录锁，但不可以继续获取X型记录锁。
当一个事务获取了一条记录的X型记录锁后，其他事务既不可以获取改获取的S型记录锁，也不可以继续获取X型记录锁。

5.2.2 间隙锁

间隙锁可以解决mysql中幻读问题。由于间隙锁细节比较多，比如聚簇索引与二级索引的间隙锁表现不同，二级索引中覆盖索引与回表的表现又不同。所以单独拿出一盘文章来详细聊聊，此处不再介绍。

5.2.3 临键锁

临键锁可以看做是间隙锁和记录锁的结合，也跟间隙锁放在同一篇文章里聊。

5.2.4 插入意向锁

5.3 页锁

页锁就是在页的粒度上进行锁定，锁定的数据资源比行锁要多，因为一个页中可以有多个行记录。当我们使用页锁的时候，会出现数据浪费的现象，但这样的浪费最多也就是一个页上的数据行。页锁的开销介于表锁和行锁之间，会出现死锁。锁定的粒度介于表锁和行锁之间，并发度一般。

每个层级的锁数量是有限制的，因为锁会占用内存空间，锁空间的大小是有限的。当某个层级的锁数量超过了这个层级的阈值时，就会进行锁升级。锁升级就是用更大粒度的锁替代多个更小粒度额锁，比如InnoDB中行锁升级为表锁，这样做的好处是占用的锁空间降低了，但同时数据的并发度也下降了。

六、悲观锁和乐观锁

从对待锁的态度来看锁的话，可以将锁分成乐观锁和悲观锁，从名字中也可以看出这两种锁是两种看待数据并发的思维方式。需要注意的是，乐观锁和悲观锁并不是锁，而是锁的设计思想。

6.1 悲观锁

顾名思义，就是以悲观的态度去看待事务访问。所以为了自己的事务不被其他事务干扰，每次访问数据时都会加锁，这样其他事务想访问数据就会阻塞。悲观锁是一种思想，会通过数据库自身的锁机制来实现，从而保证数据操作的排他性。

在一些商场业务系统中，购买商品的业务可以简化为 查询商品库存-下订单-扣减库存。我们应该保证这三步是原子性操作，如果不加锁，可能最后会出现商品库存是负数的情况。而我们需要将执行的sql语句都放在一个事务中，否则达不到原子性的目的。

# 1. 查询商品库存
select quantity from items where id = 1001 for update ;
# 2. 如果库存大于0，则需要生成订单
insert into orders (……) values (……) ：
# 3. 修改商品的库存，num表示购买的数量
update items set quantity = quantity - num where id = 1001;

select …… for update 是mysql中的悲观锁。此时在items表中，if为1001的商品已经被锁定了，如果其他事务要对这个商品进行购买时，必须等待本次事务提交之后才能执行。这样就可以保证当前的数据不会被其他事务修改。

注意：select …… for update 语句执行过程中所有扫描的行都会被锁上，因此在mysql中用悲观锁，必须确定使用了索引而不是全表扫描，否则将会被这个表锁上。

悲观锁.png

小结：悲观锁不使用的场景较多，它存在一些不足，因为悲观锁大多数情况下依靠数据库的锁机制来实现，以保证程序的并发访问行，这样对数据库性能开销影响很大，特别是长事务而言，这样的开销往往无法承受,这时候就需要乐观锁。

6.2 乐观锁

乐观锁对并发事务持乐观的态度，不在乎其他事务是否修改了数据，所以乐观锁不采用数据库自身的锁机制，而是通过程序来实现的。乐观锁可以用 版本号和时间戳机制来实现。

1. 乐观锁的版本号机制

在数据表中设计一个版本字段 version,在读数据时也要把 version 字段的值查出来。然后对数据进行修改的时候，执行 update …… set version = version + 1 where version = version。此时如果有其他事务对这条数据进行了更改，则 where 条件不成立，所以本次修改就不会成功。

这种方式类似于 SVN、GIT版本管理系统，当我们修改了代码进行提交时，首先会检查当前版本号与服务器上的版本号是否一致，如果一直就可以直接提交，如果不一致就需要更新服务器上的最新代码，然后再进行提交。

2. 乐观锁的时间戳机制

时间戳和版本号机制一样，也是在更新提交的时候，将当前库里数据的时间戳和之前查出来的时间戳做比较，如果两者一致，则没有被其他事务更改过，可以更新成功，否则就更新失败。

用乐观锁实现商城业务购买：

# 1. 查询商品库存
select quantity, version from items where id = 1001 ;
# 2. 如果库存大于0，则需要生成订单
insert into orders (……) values (……) ：
# 3. 修改商品的库存，num表示购买的数量
update items 
set quantity = quantity - num, version = version + 1 
where id = 1001 and version = #{version} ;

这里我们也可以根据具体业务，因为库存不能有小于0的场景，所以还可以加一个 where quantity - num >= 0 的条件。

注意：如果数据库采用了读写分离，当 master 表中写入的数据没有及时同步到 slave 表中的时候，会造成更新一直无效的问题，此时需要强制读取master表的数据（即把select语句放到事务中即可，这时候查询的就是master表）。

6.3 两种锁的使用场景

1、乐观锁适合 读操作多的场景，相对来说写的操作比较少。优点在于 基于程序实现，不存在死锁问题，适用场景也会相对乐观，因为它阻止不了除了程序以外的数据库操作。

2、悲观锁适合写操作多的场景，因为写的操作具有排他性。采用悲观锁的方式，可以在数据层面阻止其他事务对该数据的操作权限，防止 读写和写写的冲突。

七、显式锁和隐式锁

7.1 显示锁

通过特点的语句进行加锁，我们一般称之为显示加锁，例如：

显示加共享锁：

select …… lock in share mode

显示加排他锁：

select …… for update

7.2 隐式锁

在聊隐式锁之前，我们先回顾一下记录的行格式。在 InnoDB索引数据结构一文中，提到过行格式的示意图。
Compact 行格式

在 其他信息中存在着该记录的一些隐藏信息，我们称之为 隐藏列。隐藏列包含以下三部分：

row_id: 行ID，记录的唯一标识；当用户在表中定义了主键字段就优先选择用户定义的主键，如果没有，就查找是否有定义不为null的唯一索引，如果有就把该列作为主键，如果没有MySQL就会生成一列row_id隐藏列作为主键。
trx_id: 事务的ID；记录最后一次操作该数据的事务ID。
roll_pointer: 回滚指针，指向的是该记录的上一个版本号，MySQL的MVCC主要就是通过这个字段来实现的。

一个事务在执行insert操作时，如果即将插入的间隙已经被其他事务加了 gap锁，那么本次 insert操作会阻塞，并且当前事务会在该间隙上加一个 插入意向锁，否则一般情况下 insert操作是不加锁的。那如果一个事务T1首先插入了一条记录，在未提交事务之前，其他的事务·T2·：

立即使用 S锁读取这条记录，如果允许，就会产生脏读问题。
立即修改这条记录，也就是给这条记录添加X锁，如果允许，就会产生脏写问题。

这时候上面提到过的 事务id就起作用了。事务T1 在进行 insert操作，这条记录的 trx_id就是该T1事务的id，此时T2想对该记录添加S/X锁时，首先会看一下该记录的trx_id代表的事务T1 是否处于活跃状态，如果T1处于活跃状态，那么T2就会帮T1创建一个X锁，且锁的 is_waiting属性是false，然后T2进入等待状态（也就是给自己再添加一个锁机构，is_waiting属性是 true）。

即：一个事务新插入记录时，不会产生锁结构，但是由于事务id的存在，相当于加了一个 隐式锁。其他事务在对这条记录加锁的时候，由于隐式锁的存在，会先帮助当前事务生成一个锁结构，然后自己再生成一个锁结构并进入等待状态。所以 隐式锁是一种延迟加载的机制，这样的目的是为了减少加锁的数量。

隐式锁在实际内存对象中并不含有这个锁信息，只有当产生锁等待是，隐式锁才会转换为显式锁。

隐式锁的逻辑过程

A. InnoDB的每条记录中都有一个隐含的trx_id字段，这个字段存在于聚簇索引的B+Tree中。

B. 在操作一条记录钱，首先根据记录中的 trx_id 检查该事务是否处于活动中事务（未提交）。如果是活动事务，首先将隐式锁转换为显式锁（就是为该事务添加一个锁）。

C. 检查是否有锁冲突，如果有冲突，创建锁，并设置waiting状态为等待。如果没有冲突则不加锁，跳到步骤 E。

D.等待加锁成功，被唤醒，或者超市。

E. 写数据，并将自己的事务的id 写入行记录的 trx_id 字段

八、全局锁

全局锁就是对整个数据库实例加锁。当需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（增删改查）、数据定义语句（建表、修改表结构等）和更新类事务的提交语句。全局锁的典型使用场景是做全库逻辑备份。

flush table with read lock

九、死锁

两个事务都持有对方需要的锁，并且都在等待对方先释放，并且双方都不会释放自己的锁。

9.1 举例

事务1	事务2
start transaction; update account set money = 100 where id = 1	start transaction;
	update account set money = 100 where id = 2
update account set money = 200 where id = 2
	update account set money = 100 where id = 1

9.2 产生条件

两个或以上事务。
每个事务都已经持有锁并且申请新的锁。
锁资源同事只能被同一个事务持有或者不兼容。
事务之间因为持有锁和申请锁导致彼此循环等待。

死锁的关键在于：两个或以上的事务加锁的顺序不一致。

9.3 如何处理

方式一：等待，知道超市（innodb_lock_wait_timeout = 50s）

即两个事务互相等待时，当一个事务等待时间超过设置的阈值时，就将其回滚，另外事务继续进行。这种方法简单有效，在innodb中，参数innodb_lock_wait_timeout用来设置超时时间。

缺点：对于在线服务来说，这个等待时间往往是无法接受的。假如把这个配置值改短，比如0.1s，也不合适，容易影响到普通的锁等待。

方式二：使用死锁检测进行死锁处理

innodb提供了 wait-for graph算法来主动进行死锁检测，每当加锁请求无法立即满足需要并进入等待时，该算法都会被触发。

这是一种较为主动的死锁检测机制，要求数据库保存锁的信息链表和事务等待链表两部分信息。

9.4 如何避免

合理实际索引，使业务sql尽可能通过索引定位更少的行，减少锁竞争。
调整业务逻辑sql执行顺序，避免 update/delete 长时间持有锁的sql 在事务里。
避免大事务，尽量将大事务拆成多个小事务来处理，小事务缩短锁定资源的时间，发生锁冲突的几率也更小。
在并发比较高的系统中，不要显示加锁，特别是在事务里显示加锁。如 select …… for update 语句，如果实在事务里运行了 start transation 或者设置了 autocommit 等于0，那么就会锁定所有查找到记录。
降低隔离级别。如果业务允许，将隔离级别调低，比如从 RR调整为 RC，可以避免很多因为gap锁造成的死锁。