8.7. 死锁和空间锁

一般来说，只要有并发和加锁这两种情况的共同加持下，都会有死锁的身影。
死锁的具体成因，借用我们在并发编程中的内容：

8.7.1. 死锁

8.7.1.1. 概念

是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信
而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统
处于死锁状态或系统产生了死锁。
举个例子：A 和 B 去按摩洗脚，都想在洗脚的时候，同时顺便做个头部按摩，13 技师擅长足底按摩，14 擅长头部按摩。

这个时候 A 先抢到 14，B 先抢到 13，两个人都想同时洗脚和头部按摩，于是就互不相让，扬言我死也不让你，这样的话，A 抢到 14，想要 13，B 抢到 13，想要 14，在这个想同时洗脚和头部按摩的事情上 A 和 B 就产生了死锁。怎么解决这个问题呢？
第一种，假如这个时候，来了个 15，刚好也是擅长头部按摩的，A 又没有两个脑袋，自然就归了 B，于是 B 就美滋滋的洗脚和做头部按摩，剩下 A 在旁边气鼓鼓的，这个时候死锁这种情况就被打破了，不存在了。
第二种，C 出场了，用武力强迫 A 和 B，必须先做洗脚，再头部按摩，这种情况下，A 和 B 谁先抢到 13，谁就可以进行下去，另外一个没抢到的，就等着，这种情况下，也不会产生死锁。

所以总结一下：
死锁是必然发生在多操作者（M>=2 个）情况下，争夺多个资源（N>=2 个，且 N<=M）才会发生这种情况。很明显，单线程自然不会有死锁，只有 B 一个去，不要 2 个，打十个都没问题；单资源呢？只有 13，A 和 B 也只会产生激烈竞争，打得不可开交，谁抢到就是谁的，但不会产生死锁。同时，死锁还有几个要求，
1、争夺资源的顺序不对，如果争夺资源的顺序是一样的，也不会产生死锁；
2、争夺者拿到资源不放手。

8.7.1.2. 学术化的定义

死锁的发生必须具备以下四个必要条件。
1）互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内
某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，
直至占有资源的进程用毕释放。
2）请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源
请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其
它资源保持不放。
3）不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只
能在使用完时由自己释放。
4）环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，
即进程集合{P0，P1，P2，···，Pn}中的 P0 正在等待一个 P1 占用的资源；P1
正在等待 P2 占用的资源，……，Pn 正在等待已被 P0 占用的资源。

理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和解除死锁。
只要打破四个必要条件之一就能有效预防死锁的发生。
打破互斥条件：改造独占性资源为虚拟资源，大部分资源已无法改造。
打破不可抢占条件：当一进程占有一独占性资源后又申请一独占性资源而无法满足，则退出原占有的资源。
打破占有且申请条件：采用资源预先分配策略，即进程运行前申请全部资源，满足则运行，不然就等待，这样就不会占有且申请。
打破循环等待条件：实现资源有序分配策略，对所有设备实现分类编号，所有进程只能采用按序号递增的形式申请资源。
避免死锁常见的算法有有序资源分配法、银行家算法。

8.7.1.3. MySQL 中的死锁

所以 MySQL 中的死锁的成因是一样的。
会话 1：

begin;
select * from teacher where number = 1 for update;

会话 2：

begin;
select * from teacher where number = 3 for update;

会话 1：

select * from teacher where number = 3 for update;

可以看到这个语句的执行将会被阻塞
会话 2：

select * from teacher where number = 1 for update;

MySQL 检测到了死锁，并结束了会话 2 中事务的执行，此时，切回会话 1，发现原本阻塞的 SQL 语句执行完成了。

同时通过

show engine innodb status\G

可以看见死锁的详细情况：

8.7.2. Predicate Locks for Spatial Indexes

从 MySQL5.7 开始 MySQL 整合了 boost.geometry 库以更好的支持空间数据类型，并支持在在 Spatial 数据类型的列上构建索引，在 InnoDB 内，这个索引和普通的索引有所不同，基于 R-TREE 的结构，目前支持对 2D 数据的描述，暂不支持 3D.
R-TREE 和 BTREE 不同，它能够描述多维空间，而多维数据并没有明确的数据顺序，因此无法在 RR 隔离级别下构建 NEXT-KEY 锁以避免幻读，因此 InnoDB使用称为 Predicate Lock 的锁模式来加锁，会锁住一块查询用到的被称为MBR(minimum boundingrectangle/box)的数据区域。 因此这个锁不是锁到某个具
体的记录之上的，可以理解为一种 Page 级别的锁。
Predicate Lock 和普通的记录锁或者表锁（如上所述）存储在不同的 lock hash中，其相互之间不会产生冲突。