-
没有索引的表（假设锁住记录）
首先我们有三张表，一张没有索引的 t1，一张有主键索引的 t2，一张有唯一索引的 t3。 我们先假设 InnoDB 的锁锁住了是一行数据或者一条记录。
我们先来看一下 t1 的表结构，它有两个字段，int 类型的 id 和 varchar 类型的 name。 里面有 4 条数据，1、2、3、4。
ts12.png
现在我们在两个会话里面手工开启两个事务。 在第一个事务里面，我们通过 where id =1 锁住第一行数据。
在第二个事务里面，我们尝试给 id=3 的这一行数据加锁，大家觉得能成功吗？ 很遗憾，我们看到红灯亮起，这个加锁的操作被阻塞了。这就有点奇怪了，第一个事务锁住了 id=1 的这行数据，为什么我不能操作 id=3 的数据呢？
我们再来操作一条不存在的数据，插入 id=5。它也被阻塞了。实际上这里整张表都被锁住了。所以，我们的第一个猜想被推翻了，InnoDB 的锁锁住的应该不是 Record。 那为什么在没有索引或者没有用到索引的情况下，会锁住整张表？这个问题我们先留在这里。 我们继续看第二个演示。
-
有主键索引的表
我们看一下 t2 的表结构。字段是一样的，不同的地方是 id 上创建了一个主键索引。 里面的数据是 1、4、7、10。
ts15.png
在第一个事务里面，我们通过 name 字段去锁定值是 4 的这行数据。
在第二个事务里面，尝试获取一样的排它锁，肯定是失败的，这个不用怀疑。
在这里我们怀疑 InnoDB 锁住的是字段，所以这次我换一个字段，用 id=4 去给这行 数据加锁，大家觉得能成功吗？ 很遗憾，又被阻塞了，说明锁住的是字段的这个推测也是错的，否则就不会出现第 一个事务锁住了 name，第二个字段锁住 id 失败的情况。
既然锁住的不是 record，也不是 column，InnoDB 里面锁住的到底是什么呢？在这 三个案例里面，我们要去分析一下他们的差异在哪里，也就是这三张表的结构，是什么 区别导致了加锁的行为的差异？其实答案就是索引。InnoDB 的行锁，就是通过锁住索引来实现的。
我们还有两个问题没有解决：
1、为什么表里面没有索引的时候，锁住一行数据会导致锁表？ 或者说，如果锁住的是索引，一张表没有索引怎么办？
所以，一张表有没有可能没有索引？
1）如果我们定义了主键(PRIMARY KEY)，那么 InnoDB 会选择主键作为聚集索引。
2）如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索 引作为主键索引。
3）如果也没有这样的唯一索引，则 InnoDB 会选择内置 6 字节长的 ROWID 作为隐藏的聚集索引，它会随着行记录的写入而主键递增。
所以，为什么锁表，是因为查询没有使用索引，会进行全表扫描，然后把每一个隐藏的聚集索引都锁住了。
2、为什么通过唯一索引给数据行加锁，主键索引也会被锁住？
大家还记得在 InnoDB 里面，当我们使用辅助索引的时候，它是怎么检索数据的吗？ 辅助索引的叶子节点存储的是什么内容？
在辅助索引里面，索引存储的是二级索引和主键的值。比如name=4，存储的是name 的索引和主键 id 的值 4。
而主键索引里面除了索引之外，还存储了完整的数据。所以我们通过辅助索引锁定 一行数据的时候，它跟我们检索数据的步骤是一样的，会通过主键值找到主键索引，然后也锁定。
四，锁的算法
我们先来看一下我们测试用的表，t2，这张表有一个主键索引。 我们插入了 4 行数据，主键值分别是 1、4、7、10。 为了让大家真正理解这三种行锁算法的区别，我们需要了解一下三种范围的概念。 因为我们用主键索引加锁，我们这里的划分标准就是主键索引的值。
ts17.png
这些数据库里面存在的主键值，我们把它叫做 Record，记录，那么这里我们就有 4 个 Record。
根据主键，这些存在的 Record 隔开的数据不存在的区间，我们把它叫做 Gap，间隙，它是一个左开右开的区间。
最后一个，间隙（Gap）连同它左边的记录（Record），我们把它叫做临键的区间， 它是一个左开右闭的区间。
t2 的主键索引，它是整型的，可以排序，所以才有这种区间。如果我的主键索引不是整形，是字符怎么办呢？字符可以排序吗？ 用 ASCII 码来排序。 我们已经弄清楚了三个范围的概念，下面我们就来看一下在不同的范围下，行锁是怎么表现的。
-
记录锁
第一种情况，当我们对于唯一性的索引（包括唯一索引和主键索引）使用等值查询，精准匹配到一条记录的时候，这个时候使用的就是记录锁。 比如 where id = 1 4 7 10 。 这个演示我们在前面已经看过了。我们使用不同的 key 去加锁，不会冲突，它只锁 住这个 record。
-
间隙锁
第二种情况，当我们查询的记录不存在，没有命中任何一个 record，无论是用等值查询还是范围查询的时候，它使用的都是间隙锁。
举个例子，where id >4 and id <7，where id = 6。
ts18.png
重复一遍，当查询的记录不存在的时候，使用间隙锁。 注意，间隙锁主要是阻塞插入 insert。相同的间隙锁之间不冲突。
Gap Lock 只在 RR 中存在。如果要关闭间隙锁，就是把事务隔离级别设置成 RC， 并且把 innodb_locks_unsafe_for_binlog 设置为 ON。 这种情况下除了外键约束和唯一性检查会加间隙锁，其他情况都不会用间隙锁。
-
临键锁
第三种情况，当我们使用了范围查询，不仅仅命中了 Record 记录，还包含了 Gap 间隙，在这种情况下我们使用的就是临键锁，它是 MySQL 里面默认的行锁算法，相当于记录锁加上间隙锁。
其他两种退化的情况： 唯一性索引，等值查询匹配到一条记录的时候，退化成记录锁。
没有匹配到任何记录的时候，退化成间隙锁。
比如我们使用>5 <9， 它包含了记录不存在的区间，也包含了一个 Record 7
为什么要锁住下一个左开右闭的区间？
——就是为了解决幻读的问题.
-
小结：隔离级别的实现
所以，我们再回过头来看下这张图片，为什么 InnoDB 的 RR 级别能够解决幻读的问题，就是用临键锁实现的。
我们再回过头来看下这张图片，这个就是MySQL InnoDB里面事务隔离级别的实现。
最后我们来总结一下四个事务隔离级别的实现：
除了两种特殊情况——外键约束检查(foreign-key constraint checking)以及重复键检查(duplicate-key checking)时会使用间隙锁封锁区间。 所以 RC 会出现幻读的问题。
- Read Uncommited RU 隔离级别：不加锁。
- Serializable 所有的 select 语句都会被隐式的转化为 select ... in share mode，会 和 update、delete 互斥。 这两个很好理解，主要是 RR 和 RC 的区别？
- Repeatable Read RR 隔离级别下，普通的 select 使用快照读(snapshot read)，底层使用 MVCC 来实现。 加锁的 select(select ... in share mode / select ... for update)以及更新操作 update, delete 等语句使用当前读（current read），底层使用记录锁、或者间隙锁、 临键锁。
- Read Commited RC 隔离级别下，普通的 select 都是快照读，使用 MVCC 实现。 加锁的 select 都使用记录锁，因为没有 Gap Lock。
那么死锁需要满足什么条件？死锁的产生条件：
因为锁本身是互斥的，（1）同一时刻只能有一个事务持有这把锁，（2）其他的事务需要在这个事务释放锁之后才能获取锁，而不可以强行剥夺，（3）当多个事务形成等待环路的时候，即发生死锁。
举例：
理发店有两个总监。一个负责剪头的 Tony 总监，一个负责洗头的 Kelvin 总监。
Tony 不能同时给两个人剪头，这个就叫互斥。
Tony 在给别人在剪头的时候，你不能让他停下来帮你剪头，这个叫不能强行剥夺。
如果Tony的客户对Kelvin总监说：你不帮我洗头我怎么剪头？Kelvin的客户对Tony 总监说：你不帮我剪头我怎么洗头？这个就叫形成等待环路。
如果锁一直没有释放，就有可能造成大量阻塞或者发生死锁，造成系统吞吐量下降， 这时候就要查看是哪些事务持有了锁。
- 查看锁信息（日志）
SHOW STATUS 命令中，包括了一些行锁的信息：
show status like 'innodb_row_lock_%';
当然，死锁的问题不能每次都靠 kill 线程来解决，这是治标不治本的行为。我们应该尽量在应用端，也就是在编码的过程中避免。 有哪些可以避免死锁的方法呢？
-
死锁的避免
1、 在程序中，操作多张表时，尽量以相同的顺序来访问（避免形成等待环路）；
2、 批量操作单张表数据的时候，先对数据进行排序（避免形成等待环路）；
3、 申请足够级别的锁，如果要操作数据，就申请排它锁；
4、 尽量使用索引访问数据，避免没有 where 条件的操作，避免锁表；
5、 如果可以，大事务化成小事务；
6、 使用等值查询而不是范围查询查询数据，命中记录，避免间隙锁对并发的影响。
