MySQL实战45讲学习笔记：第七讲

一、两阶段锁

1、持有哪些锁，以及在什么时候释放

我先给你举个例子。在下面的操作序列中，事务 B 的 update 语句执行时会是什么现象呢？

假设字段 id 是表 t 的主键。

这个问题的结论取决于事务 A 在执行完两条 update 语句后，持有哪些锁，以及在什么时候 释放。你可以验证一下：实际上事务 B 的 update 语句会被阻塞，直到事务 A 执行 commit 之后，事务 B 才能继续执行。

知道了这个答案，你一定知道了事务 A 持有的两个记录的行锁，都是在 commit 的时候才释

放的。

在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。

Note:如果你的事务中需要锁多个行，要 把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。

二、死锁和死锁检测

当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导

致这几个线程都进入无限等待的状态，称为死锁。这里我用数据库中的行锁举个例子。

 这时候，事务 A 在等待事务 B 释放 id=2 的行锁，而事务 B 在等待事务 A 释放 id=1 的行 锁。 事务 A 和事务 B 在互相等待对方的资源释放，就是进入了死锁状态。当出现死锁以后，

有两种策略：

1.一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数

innodb_lock_wait_timeout 来设置。

2.另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事

务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。

注意:死锁检测要消耗大量的cpu资源

你可以考虑通过将一行改成逻辑上的多行来减少锁冲突。还是以影院账户为例，可以考虑放在

多条记录上，比如 10 个记录，影院的账户总额等于这 10 个记录的值的总和。这样每次要给

影院账户加金额的时候，随机选其中一条记录来加。这样每次冲突概率变成原来的 1/10，可

以减少锁等待个数，也就减少了死锁检测的 CPU 消耗。

.

三、小结

1.如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁的申请时机尽量往后放。

2.但是，调整语句顺序并不能完全避免死锁。所以我们引入了死锁和死锁检测的概念，以及提供了三个方案，来减少死锁对数据库的影响。减少死锁的主要方向，就是控制访问相同
资源的并发事务量。

最后，我给你留下一个问题吧。如果你要删除一个表里面的前 10000 行数据，有以下三种方法可以做到：

• 第一种，直接执行 delete from T limit 10000;
• 第二种，在一个连接中循环执行 20 次 delete from T limit 500;
• 第三种，在 20 个连接中同时执行 delete from T limit 500。

你会选择哪一种方法呢？为什么呢？

选择第二种

1.直接delete 10000可能使得执行事务时间过长

2.效率慢点每次循环都是新的短事务，并且不会锁同一条记录

3.效率虽高，但容易锁住同一条记录，发生死锁的可能性比较高