Mysql心路历程：Mysql各类锁机制(入门篇)

这一篇文章是本人数据库的第二篇，也是对数据库学习的阶段性总结。对于数据库锁的了解，是区分程序员，尤为是Java程序员，中高级的一个重要标志。也是平常，咱们开发中，常常碰到坑的地方。每每，咱们无脑的CURD过程当中，其实已经出现问题了，锁问题，可是咱们并无发现，你那是没有被大访问量冲击。一旦一朝咱们冲击到了，那损失和锅，是要本身承担下来的。很少说，咱们接下来就来一步步看看Mysql的锁机制。

1、Mysql锁的类型

总体上，Mysql锁的类型，从全局的到细节的，包含以下几个：

• 全局锁
• 表级锁
  • 普通的表锁
  • MDL (元数据锁)
• 行锁
  • 读锁(共享锁)
  • 写锁(排他锁、叉锁)
• 间隙锁
  • Next-key lock

大概上，咱们平常生产学习中，所能接触到的就这几大种类了(我的的脑容量也就能掌握这么多了，(⊙﹏⊙)b)，接下来，咱们一个个的说说。

2、 全局锁

顾名思义，全局锁就是对整个数据库实例加锁。Mysql提供了一个加锁的语句：Flush tables with read lock (FTWRL)。它能使整个实例上面，只读，全部的写和更新，都会被阻塞。全局锁的使用经典的使用场景是作全局的数据备份使用，具体的操做，可能平时咱们碰到很少，不过要了解几点：

• 每次全局备份过程当中，若是是InnoDB引擎彻底能够经过MVCC建立一致性视图，来保证不受备份中，其余操做的影响，问题是不必定全部的数据引擎都是InnoDB
• 咱们一样能够经过set global readonly=true 来进行只读性的设置，可是和FTWRL的区别以下：
  • 有些数据库把第一种模式用做，设置成备库的只读限制，而不是用来作备份的，影响面比较大
  • 异常处理机制不同：FTWRL这种机制，若是设置以后，客户端异常断开链接了，数据库会主动释放全局的锁，恢复正常；而set这种方式，客户端异常断开了，就不会恢复原状，数据库会一直只读，影响很大。
• 具体对数据库的全局锁，不只仅阻塞增删改操做(DML)，对数据库表的增删改字段（DDL）也会被阻塞

3、表级锁

咱们首先要知道的是，每次进行select操做或者DML的时候，对表加的都是MDL的读锁，而进行DDL的时候，对表加的是MDL的写锁，让咱们首先来个印象。接下来来看看普通的表锁与MDL（元数据锁meta data lock）的区别。

一、普通的表锁

普通的表锁也是分读锁与写锁，数据库提供语句操做：lock tables … read/write，使用unlock tables进行释放锁。具体注意的点是：加了普通的表锁以后，对当前加锁线程接下来的数据库操做，都是有影响的。

举个例子：若是A线程使用语句lock tables t1 read, t2 write; 这个语句，那么，其余线程写t1和读写t2都会被阻塞；同时线程A再进行unlock以前，也只能读t1和读写t2，连写t1都是不被容许的。天然也不能访问其余的表

在没有出现行锁以前，都是经过表锁进行并发控制的，上面例子可见，影响面仍是太大，限制太严格了。

二、元数据锁(MDL)

MDL不须要主动加锁，每当咱们访问一个数据表的时候，会自动被加上，做用是防止在咱们进行表的操做的时候，进行了表结构的变动。再5.5这个版本中被引入了Mysql中：

• 当对一个表进行增删改查的时候，加MDL的读锁
• 当进行一个表的结构变动的时候，加MDL的写锁

读写锁的MDL之间的互斥关系是：

• 读锁与读锁不互斥
• 读锁与写锁互斥
• 写锁与写锁互斥

具体有个经典的例子：常常发生的是，咱们给一个表加了个一个字段或者几个字段，很当心了，可是加的过程当中，直接整个表挂了，接下来的操做都失败了或者不返回。接下来咱们就看看具体的操做过程：

sessionA	sessionB	sessionC	sessionD
begin;
select * from t limit1
	select * from t limit1
		alter table t add f int (block)
			select * from t limit1 (block)

可见，咱们sessionC操做以后，因为sessionA是没有结束事务的，咱们MDL会随着事务的开启而加锁，事务的结束而释放锁，因此，sessionA这时候保持住了MDL的读锁。而后sessionC想要获取MDL的写的时候，因为读写互斥，sessionC就被阻塞了。接下来的语句，也都执行不了了，由于接下俩的语句要申请MDL的读锁，而有写锁已经在阻塞状态，读锁又要排队等这个写锁执行释放，那接下来的现象可想而知。

咱们如何安全的对一个表进行加字段的操做呢：

• 在information_schema库里面的innodb_tx表中，能够查到当前正在执行的事务，若是是一个长事务，咱们能够先考虑kill掉这个事务
• 若是是频繁访问的断事务比较多的状况，咱们可使用alter table tablename wait N add col这种类型的操做，若是拿不到MDL写锁，一段时间会释放阻塞，不长期影响数据库。

4、行锁

这个过程比较复杂，首先，咱们来看看，Mysql加行锁，是使用两阶段加锁策略的，咱们看看什么叫作两阶段加锁：

两阶段锁协议，整个事务分为两个阶段，前一个阶段为加锁，后一个阶段为解锁。在加锁阶段，事务只能加锁，也能够操做数据，但不能解锁，直到事务释放第一个锁，就进入解锁阶段，此过程当中事务只能解锁，也能够操做数据，不能再加锁。两阶段锁协议使得事务具备较高的并发度，由于解锁没必要发生在事务结尾。它的不足是没有解决死锁的问题，由于它在加锁阶段没有顺序要求。如两个事务分别申请了A, B锁，接着又申请对方的锁，此时进入死锁状态。

一、何时加行锁

正常，咱们select语句时候，是不会添加行锁的，只会加上MDL的读锁，即便这条语句是全表扫描，也不会加行锁，只不过全表扫描，查询较慢罢了，并不会由于锁的问题而对其余操做进行阻塞。下面是我总结的一些加行锁的场景：

• select * from t where id = 1 in share model 对主键为1的这一行，加行锁，共享锁
• select * from t where id = 1 for update 对主键为1的这一行，加行锁，排它锁，叉锁
• update t set col1 = 1 where id =1 对主键为1的这一行加行锁，排它锁，叉锁
• update t set col1 = 1 where col2 =1 若是col2没有索引，那么是加普通表锁；若是col2是非惟一索引，对全部col2为1的行，加行锁；若是col2是惟一索引，对col2为1的这一行，加行锁。行锁都是排它锁

p.s.:固然上面全部所列取的操做，都是首先加了MDL的读锁的

二、加行锁的影响

行锁，之因此存在，就是提升并发度的。取代之前，咱们要整表进行加锁，而引发同一时刻，只能有一个线程对数据表进行增删改的操做，下面咱们看一个具体的数据库操做：

事务A	事务B
begin;
update t set k = k+1 where id = 1;
update t set k = k+2 where id = 2;
	begin;
	update t set k = k+3 where id = 1;
commit;

• 事务B的update会被阻塞，由于id为1的这行行锁被事务A所持有
• begin的时候，没有任何行锁被持有，只有当具体操做进行是，依次请求MDL的读锁，这一行的排它行锁
• 全部，当前事务持有的行锁，语句执行完都不会释放，知道commit以后才释放

因此，按照这种逻辑，越是并发度高的数据表，越要靠事务的后面写，由于持有行锁时间短，影响并发度的时间越短。

三、这里咱们引出死锁

首先咱们看接下来的这个模拟操做：

事务A	事务B
begin;
update t set k = k+1 where id = 1;	begin;
	update t set k = k+3 where id = 2;
update t set k = k+2 where id = 2;
	update t set k = k+3 where id = 1;

这就是一个经典的死锁场景，咱们来分析下：

• 事务A的update t set k = k+1 where id = 1;获取了id为1这一行的行锁(排它锁)

• 事务B的update t set k = k+3 where id = 2;获取了id为2这一行的行锁

• 事务A的update t set k = k+2 where id = 2;要获取id为2的行锁，而获取不到，阻塞

• 事务B的update t set k = k+3 where id = 1;要获取id为1的行锁，获取不到，阻塞

对于这种，Mysql有两种机制进行处理：

• innodb_lock_wait_timeout能够经过这个参数，进行设置锁等待时间，超过这个时间，阻塞的进程释放全部持有的锁，回滚。
• innodb_deadlock_detect经过设置为on，能主动监测死锁，经过回滚死锁联调中的一个事物，来解决死锁

第一种状况虽然能控制，死锁，可是时间很差设置，例如咱们设置一个10s，若是一个线程被锁住，要等待10s才能进行回滚，并发度天然不高，若是我设置低了，1s，那么一个正常等待的，并不是死锁，也会被回滚。如此一来得不偿失。下面重点说说主动死锁检测

四、主动死锁检测

每当吧innodb_deadlock_detect设置成on，MySQL会主动检测死锁：

• 一个线程加入
• 即将被等待其余线程的锁而堵住
• 判断当前线程持有的锁，是否堵住了其余系统中正在运行的线程
• 若是是，将回滚当前线程的事务

看起来很好，而后会有代价：每次对比是否当前线程堵住了其余线程这一步，会对比全部系统正在执行的线程，时间复杂度是O(n)。当前执行的线程数少不成问题，若是是1000个正在执行的线程，那么这就是100w次的对比，这个过程极度消耗CPU资源。结果可能检测出没有死锁，而后会发现：最终CPU飚的老高，然而执行的条数没几个！解决办法有下面几个：

• 临时关掉innodb_deadlock_detect，可是这样会有不少超时，不实用
• 控制数据库的并发度：能够从中间件这层控制(Java这里)，或者有能力的从数据库这一层进行控制
• 业务字段拆分：例如咱们将一行记录拆分红多行，让一行的并发度降低(例如并发扣减id为1这一行的金额，咱们能够拆分红id为100，id为200，id为300这三行的金额，最后要查询的时候，将这三行相加)

5、结束

下面一篇文章，会重点讲间隙锁，这个内容最为复杂，涉及到了所谓数据库解决幻读的机制问题，特别单独抽出一章来说解。