MySQL的锁

项目里碰到了一个死锁的问题，发现自己在MySQL锁这块的知识有点欠缺，就紧急补充一下，然后在这里记录一下。

首先就是共享锁和排他锁：

字面意思，共享锁就是一个锁可以让多个事务共享，这一般是用在查询的时候，锁住正在查询的数据不让其他事务对数据进行修改，但是可以让其他人对加锁的数据同时进行查询。所以共享锁一般是读锁。

相对的排他锁，获取之后其他事务就不能对加了排他锁的数据进行加锁了。

一般的查询语句是不加锁的，不受排他锁和共享锁的影响，即所要查询的对象即使加了锁，普通查询该查还是查。

另外加了共享锁的数据还是可以加共享锁，但是不能加排他锁；但是加了排他锁的数据则不能增加其他任何锁。

然后是关于范围的分类：
    行锁（Record Locks）
        行锁一定是作用在索引上的

    间隙锁（Gap Locks）
        间隙锁在本质上是不区分共享间隙锁或排他间隙锁的，而且间隙锁是不排他的，即两个事务可以同时持有包含共同间隙的间隙锁。
    这里的共同间隙包括两种场景：其一是两个间隙锁的间隙区间完全一样；其二是一个间隙锁包含的间隙区间是另一个间隙锁包含间隙区间的子集。
    间隙锁本质上是用于阻止其他事务在该间隙内插入新记录，而自身事务是允许在该间隙内插入数据的。也就是说间隙锁的应用场景包括并发读取、并发更新、并发删除和并发插入。
        在RU（读未提交）和RC（读已提交）两种隔离级别下，即使你使用select ... in share mode或select ... for update，也无法防止幻读（读后写的场景）。因为这两种隔离级别下只会有行锁，而不会有间隙锁。
    这也是为什么示例中要规定隔离级别为RR的原因。

    临键锁（Next-key Locks）
        临键锁是行锁+间隙锁，即临键锁是是一个左开右闭的区间，比如（3，5]。

    意向共享锁/意向排他锁（Intention Shared and Exclusive Locks）
        意向共享锁/意向排他锁属于表锁，且取得意向共享锁/意向排他锁是取得共享锁/排他锁的前置条件。

    插入意向锁（Insert Intention Locks）
        这段话表明尽管插入意向锁是一种特殊的间隙锁，但不同于间隙锁的是，该锁只用于并发插入操作。如果说间隙锁锁住的是一个区间，那么插入意向锁锁住的就是一个点。
    因而从这个角度来说，插入意向锁确实是一种特殊的间隙锁。与间隙锁的另一个非常重要的差别是：尽管插入意向锁也属于间隙锁，但两个事务却不能在同一时间内一个拥有间隙锁，
    另一个拥有该间隙区间内的插入意向锁（当然，插入意向锁如果不在间隙锁区间内则是可以的）。这里我们再回顾一下共享锁和排他锁：共享锁用于读取操作，而排他锁是用于更新或删除操作。
    也就是说插入意向锁、共享锁和排他锁涵盖了常用的增删改查四个动作。