当前位置：首页 > 数据库 > MySQL教程 > 一起聊聊Mysql两阶段锁和死锁 > 正文

一起聊聊Mysql两阶段锁和死锁

来源：这里教程网 时间：2026-02-28 15:51:10 作者：

本篇文章给大家带来了关于mysql锁的相关知识，其中主要介绍了mysql 两阶段锁和死锁，下面一起来看一下，希望对大家有帮助。

两阶段锁

概念

讲的是

InnoDB
如何处理行锁的上锁，释放锁的行为。

在事务使用过程中，对记录以主键为条件删改时，会立刻加上排他锁，这完成了上锁阶段。

当删改动作完成后，这个锁并不会立即释放，需要等至事务提交时，才会释放锁。

引发的问题-阻塞

事务 A 事务 B
begin;
update t set k=k+1 where id=1;
update t set k=k+1 where id=2;

begin;
update t set k=k+2 where id=1;
commit;

根据两阶段锁协议，

事务 B
将会因为
id=1
的数据被
事务 A
上了锁，而阻塞，因为
事务 B
需要拿到锁后才能进行下一步操作。

上述这个问题，可能看似问题不大，但是如果不止是

事务 B
，还有
事务 C
，
事务 D
，等等很多，做的是跟
事务 B
一样的事，问题就大了，被阻塞的线程就会多了起来。【推荐学习：MySQL视频教程】

如何处理上述问题

我们应该尽量将可能会引起阻塞的语句，放到事务的最后面操作，例如上述

事务 A
例子中的
id=1
的语句，它和第二句的执行并没有什么关联关系，可是它是容易引起阻塞的语句，因为在
事务 B
中也要对这一行数据做锁操作（在各类事务中频繁使用的，如公司的收付款账号余额记录，即
**热点行**
），但是却在事务一开始就拿到锁了。

本质上，是缩短了拿锁时间和释放锁之间的时间。即持有锁的时间缩短，以此减少锁引起的阻塞。

死锁

概念

两个线程，互相在等待对方释放资源。

在两个事务A，B中。

事务 A
拿到了
资源 A
的锁。

 

事务 B
拿到了
资源 B
的锁。

 

事务 A
去拿
资源 B
的锁。

 

事务 B
去拿
资源 A
的锁。

很明显，步骤 3，4中，事务 A，B 都想去拿锁，但是又都拿不到，因为对方都还没有释放该资源的锁。这种现象就是死锁。

引发的问题-死锁

在

InnoDB
中，有一个拿锁的等待时间配置，超过这个时间就会抛出异常，这个时间默认是
50
秒。通常来说，有一个接口需要
50
秒后才响应是不可接受的。
innodb_lock_wait_timeout
。

那是不是把这个配置时间设置短一点就行了？比如

1
秒？

应该是不可以的，因为可能会影响到你的正常业务，或许你的业务导致你的事务执行时间本身就比较长，超过

1
秒。超出这个时间会抛出异常，你的正常业务就被影响了。

那该如何处理上述问题

在

InnoDB
中，还有一个自动检测死锁并处理的配置。它是默认开启的，在极端情况下，虽然能处理问题，但是对
CPU
消耗特别大。

它原理是在事务中即将要上锁的时候，会去检测其他并发线程，有没有将此资源锁住，如果检测到某个

线程A
有，然后再会去检测
线程A
的依赖有没有被其他并发线程锁住，如此循环往复，最终判断这些锁会不会形成死锁。

可以看出，线程越多，检测成本就越大。

innodb_deadlock_detect
。

仅代表个人当前的学习做出的对此问题的处理和总结：

1.关闭死锁检测，将拿锁时间配置缩短至预估的最高时间，通常不会超过

15
秒，超过
15
秒后，需要有重试机制。

2.开启死锁检测，在应用层控制并发连接数，使用连接池控制

Mysql
的连接数，在服务层限制
Mysql
最大连接数。

以上是对怎样减少行锁性能影响的学习总结。

编辑推荐：

相关推荐

最新软件资讯

聊聊怎么用MySQL快速实现一个推荐算法
聊聊怎么用MySQL快速实现一个推荐算法

热文推荐

天极热推