Mysql(7) - 锁

          在之前的章节中我们提到，事务的原子性和一致性是由undo日志保证的，持久性是由redo日志保证的，隔离性是由锁机制实现的。今天我们就来梳理一下mysql的锁机制。

        在数据库中，数据是一种供许多用户共享的资源。为了保证数据的一致性，我们需要对并发的操作进行优化，因此产生了锁。同时锁机制也为实现mysql的各个隔离级别提供了保证，锁冲突也是影响数据库并发性能的一个重要因素，因此锁对数据库的重要程度显而易见。

        并发问题有两种解决方案：
        方案一：读操作利用多版本并发控制（MVCC），写操作通过加锁来保护

        方案二：读写操作都使用锁来保护

以上两种方案都有其优缺点，采用MVCC方式进行读操作的话，读写操作之前是不会阻塞的，并发性能更高。采用都加锁的方式的话，读写操作之间需要排序执行等待锁释放，会影响性能。

        锁的分类图如下

这里我们介绍几个比较有代表意义的锁

从数据操作的类型划分为：读锁和写锁

读锁：也叫共享锁(share lock) ，表示为S，针对同一个数据，多个事务之间的读操作可以同时进行而不会被阻塞

写锁：也叫排他锁(Exclusive lock),表示为X，X锁是比较霸道的锁，在当前事务的写操作没有完成之前，其他事务不能对该数据进行读和写操作，保证了数据的安全。

MyIsam引擎中只有表锁没有行锁，但是Innodb的写锁和读锁既可以加在表上也可以加在行上。

从数据操作的粒度划分：表级锁，页级锁，行锁

表锁：分为表级别的S锁和X锁

顾名思义，表锁的作用范围是一整张数据表，mysql的表锁有两种模式，表共享读锁和表独占写锁。下表展示了不同类型表锁之间的兼容关系 

 意向锁 ： 意向锁是一种表锁，意向锁分为两种：意向共享锁（IS）和意向排他锁(IX)

当有事务对数据表中的某一行或几行数据加了锁时，同时会给当前表设置一个标识，标识当前表中已经有行锁了，当有事务想对表加锁时，就不需要一行一行遍历去找有没有行锁会和自己不兼容，只要看意向锁就可以决定自己是否该加表锁。其他事务想加共享表锁时，需要先获取该表的意向共享锁，想加排他表锁时，需要先获取该表的意向排他锁。  注意：意向锁不会和行锁互斥，也就是说意向锁并不会影响并发事务对行加锁。意向锁无法手动创建，由系统自动创建。

元数据锁：（MDL锁），表锁的一种。假如一个事务正在对表中的数据进行遍历查询，此时另一个事务对该表进行了结构上的变更，那前一个事务遍历的结果就可能不对，所以就有元数据锁的出现。因此，当对一个表做增删改查（DML）操作时，给表加MDL读锁，当其他事务只是对表做增删改操作时，不会阻塞。当对一个表做结构变更操作（DDL）时，加MDL写锁，其他事务此时不能对表做DML操作和DDL操作。

InnoDB行锁（MyIsam不支持行锁）：行锁顾名思义就是对一行数据加锁，锁的粒度更细了，也就提高了并发性能。行锁也分读锁（S锁）和写锁（X锁）。

当一个事务获取了一条记录的读锁时，其他事务可以继续获取该记录的读锁，但不可以获取该记录的写锁。

当一个事务获取了一条记录的写锁时，其他事务不能获取该记录的写锁和读锁

间隙锁（Gaps lock）

        mysql在可重复读的隔离级别下是可以解决幻读问题的，解决方案有两种，MVCC或者加锁，但是我们应该如何给还没加入的记录加锁呢？所以InnoDB提出了一种Gaps lock锁。应用场景如下

  图中id为8的记录加了gap锁，意味着不允许别的事务在id值为8的记录前面插入新纪录，也就是（3,8）这个区间 。比如有另一个事务想插入一条id为5的记录，它发现该条新纪录的下一条记录上面有一个gaps锁，所以就会阻塞本次插入操作，知道拥有这个gaps锁的事务提交之后，才可以插入。

从对待数据的态度划分为乐观锁和悲观锁，乐观锁和悲观锁并不是真实意义上的锁，只是对所锁的态度进行一个划分，是一种设计思想

悲观锁：总是假设最坏的情况，他认为每次去取数据的时候数据都会被别人修改，所以在每次拿数据的时候都会上锁，防止别的线程修改数据。当别的线程想要访问数据时都要阻塞，Java中的synchronized和Reentrantlock就是悲观锁的实现。悲观锁适合多写的场景，因为写操作具有排他性。

乐观锁：和悲观锁相反，它觉得自己取数据的时候别人肯定不会修改这个数据，不会对这个数据先上锁，但是在取数据时会判断一个在此期间别的线程有没有对这个数据进行过更新，也就是不采用数据库本身的锁机制，而是通过程序来实现，在程序上我们可以采用版本号机制或者CAS机制实现。乐观锁适用于多读的场景。

死锁：指两个事务或多个事务之间互相持有对方所需要的的锁，并且都不愿意主动释放，造成无法破局的尴尬场景

破解死锁有两种策略，一种是等待，直到超时，超时时间可以通过参数innodb_lock_wait_timeout来设置；

另一种策略是发起死锁检测，发现死锁后，主动混gun死锁链条中的某一个事务，将持有最少排它锁的事务进行回滚，让其他事务得以继续执行，将参数innodb_deadlock_detect设置为on，表示开启死锁检测。