文章目录

• • 前言
  • • 全局锁
    • • 全局锁使用场景
    • 表锁
    • 行锁
    • • 两段锁
      • 死锁与死锁检测
  • 小结

前言

数据库设计锁的初衷是处理并发问题，作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。

根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。

全局锁

顾名思义，全局锁就是对整个数据库实例加锁。Mysql 提供了一个全局读锁的方法，命令是：

Flush tables with read lock (FTWRL)

可以使用以下命令解锁：

unlock tables;

这个命令可以让整个数据库处于可读的状态，使用此命令，会阻塞以下操作：

1、数据更新语句（数据的增删改）
2、数据定义语句（包括建表、修改表结构等）
3、更新类事务的提交语句

全局锁使用场景

全局锁的典型使用场景是，做全库逻辑备份。 比如，主从复制，也就是把整个库的所有表都 select 出来存成文本。

有一种做法，是通过FTWRL确保不会有其他线程对数据库做更新，然后对整个库做备份。注意，在备份过程中整个库完全处于只读状态。

那么，数据库处于可读状态的危险性：

• 如果你在主库上备份，那么在备份期间都不能执行更新，业务基本上就能停止。
• 如果你在从库上备份，那么备份期间从库不能执行主库同步过来的binlog，会导致主从延迟。

看来，加全局锁不太好，那我们看看不加全局锁，会出现什么问题呢?

不加锁的话，备份得到的库不是一个逻辑时间点，这个视图是逻辑不一致的。也就是说，由于不能在同一逻辑时间点进行备份，所以可能会出现在备份过程中，有一些增删改操作，影响备份数据的一致性。

现在的问题是，不加锁的话得不到一致性视图，那有没有办法解决呢？

答案是肯定的，就是在可重复读隔离级别下开启一个事务。

官方自带的逻辑备份工具是mysqldump。当mysqldump使用参数–single-transaction的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于MVCC的支持，这个过程中数据是可以正常更新的。

有了这个逻辑备份工具，再使用上 –single-transaction 参数，可以得到一致性视图，而且还不影响数据正常更新。多香！

那问题来了，有了“真香”工具，还用什么 FTWRL 啊，虽然能让整库处于可读状态，但还会阻塞很多正常操作。“真香”工具的前提是，引擎要支持这个隔离级别。比如，对于MyISAM这种不支持事务的引擎，如果备份过程中有更新，总是只能取到最新的数据，那么就破坏了备份的一致性。这时，我们就需要使用FTWRL命令了。

所以，single-transaction方法只适用于所有的表使用事务引擎的库。如果有的表使用了不支持事务的引擎，那么备份就只能通过FTWRL方法。

还有一种方式能让整库处于只读状态，就是：

set global readonly=true

确实readonly方式也可以让全库进入只读状态，但我还是会建议你用FTWRL方式，主要有两个原因：

1、在有些系统中，readonly的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改global变量的方式影响面更大，不建议你使用。
2、在异常处理机制上有差异。如果执行FTWRL命令之后由于客户端发生异常断开，那么MySQL会自动释放这个全局锁，整个库回到可以正常更新的状态。而将整个库设置为readonly之后，如果客户端发生异常，则数据库就会一直保持readonly状态，这样会导致整个库长时间处于不可写状态，风险较高。

业务的更新不只是增删改数据（DML)，还有可能是加字段等修改表结构的操作（DDL）。不论是哪种方法，一个库被全局锁上以后，你要对里面任何一个表做加字段操作，都是会被锁住的。

表锁

表级别的锁有两种：

1、表锁
	表锁的语法是 lock tables … read/write
	与FTWRL类似，可以用unlock tables主动释放锁，也可以在客户端断开的时候自动释放。lock tables语法除了会限制别的线程的读写外，
	也限定了本线程接下来的操作对象。
	
	举个例子, 如果在某个线程A中执行lock tables t1 read, t2 write; 这个语句，则其他线程写t1、读写t2的语句都会被阻塞。
	同时，线程A在执行unlock tables之前，也只能执行读t1、读写t2的操作。连写t1都不允许，自然也不能访问其他表。

	在还没有出现更细粒度的锁的时候，表锁是最常用的处理并发的方式。而对于InnoDB这种支持行锁的引擎，一般不使用lock tables命令
	来控制并发，毕竟锁住整个表的影响面还是太大。

2、元数据锁（meta data lock，MDL)
	MDL不需要显式使用，在访问一个表的时候会被自动加上。MDL的作用是，保证读写的正确性。
	
	在MySQL 5.5版本中引入了MDL，当对一个表做增删改查操作的时候，加MDL读锁；当要对表做结构变更操作的时候，加MDL写锁。
		(1)读锁之间不互斥，因此你可以有多个线程同时对一张表增删改查。
		(2)读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。

下面，我们来看一个事务是如何执行的？

我们可以看到session A先启动，这时候会对此表加一个MDL读锁。由于session B需要的也是MDL读锁，因此可以正常执行。

之后session C会被blocked，是因为session A的MDL读锁还没有释放，而session C需要MDL写锁，因此只能被阻塞。

如果只有session C自己被阻塞还没什么关系，但是之后所有要在此表上新申请MDL读锁的请求也会被session C阻塞。前面我们说了，所有对表的增删改查操作都需要先申请MDL读锁，就都被锁住，等于这个表现在完全不可读写了。

如果某个表上的查询语句频繁，而且客户端有重试机制，也就是说超时后会再起一个新session再请求的话，这个库的线程很快就会爆满。

所以，事务中的MDL锁，在语句执行开始时申请，但是语句结束后并不会马上释放，而会等到整个事务提交后再释放。

我们考虑一个问题，如何安全的做DDL？

首先要解决长事务，因为事务不提交就会一直占用MDL锁，可以查到当前执行中的事务。如果你要做DDL变更的表刚好有长事务在执行，
要考虑先暂停DDL，或者kill掉这个长事务。

但如果变更的是一个热点表，请求频繁，但由不得不DDL，该如何做呢？？

这时候kill可能未必管用，因为新的请求马上就来了。比较理想的机制是，在alter table语句里面设定等待时间，如果在这个指定的等待时间
里面能够拿到MDL写锁最好，拿不到也不要阻塞后面的业务语句，先放弃。之后开发人员或者DBA再通过重试命令重复这个过程。

行锁

上面，我们聊了MySQL的全局锁和表级锁，下面我们来说说MySQL的行锁。我们都知道 Mysql 的架构分为三层，Client , Server , Engine ，而 Mysql 的行级锁是在 引擎层实现的，各引擎层有自己的行锁实现方式，当然，不是所有的引擎都支持行锁，比如：MyISAM 就不支持行级锁。这也是为什么MyISAM被InnoDB取代的重要原因之一。

下面，我们来聊聊 InnoDB 的行锁，以及如何通过减少锁冲突来提高业务并发度。

顾名思义，行级锁其实很好理解，就是锁定表中的一行数据，当操作A要更新一行数据，操作B也要更新同一行数据，那操作B就要等到操作A执行结束后再执行。

下面，我们介绍一个概念，两阶段锁。

两段锁

什么是两段锁？顾名思义一下，就是锁分为了两个阶段，是的，分为加锁和解锁这两个阶段，而加锁一定是在解锁之前的。

我们来看个例子理解什么是两段锁。下面操作中，事务B的 update 语句执行会出现什么现象？假设字段 id 是表 t 的主键。

这个问题的关键在于，事务A在什么时候释放锁。

InnoDB事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。

知道了这个设定，对我们使用事务有什么帮助呢？那就是，如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。举个例子。

假设你负责实现一个电影票在线交易业务，顾客A要在影院B购买电影票。我们简化一点，这个业务需要涉及到以下操作：

1、从顾客A账户余额中扣除电影票价；
2、给影院B的账户余额增加这张电影票价；
3、记录一条交易日志。

为了保证操作的安全性，我们要把这三个步骤放到一个事务中，那你会怎么安排这三个语句的顺序呢？

试想如果同时有另外一个顾客C要在影院B买票，那么这两个事务冲突的部分就是语句2了。因为它们要更新同一个影院账户的余额，需要修改同一行数据。

根据两阶段锁协议，不论你怎样安排语句顺序，所有的操作需要的行锁都是在事务提交的时候才释放的。所以，如果你把语句2安排在最后，比如按照3、1、2这样的顺序，那么影院账户余额这一行的锁时间就最少。这就最大程度地减少了事务之间的锁等待，提升了并发度。

现在由于你的正确设计，已经提升了并发度，但是，依然没有解决你的困扰。

如果这个影院做活动，可以低价预售一年内所有的电影票，而且这个活动只做一天。于是在活动时间开始的时候，你的MySQL就挂了。你登上服务器一看，CPU消耗接近100%，但整个数据库每秒就执行不到100个事务。这是什么原因呢？

死锁与死锁检测

当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。这里我用数据库中的行锁举个例子。

这时候，事务A在等待事务B释放id=2的行锁，而事务B在等待事务A释放id=1的行锁。 事务A和事务B在互相等待对方的资源释放，就是进入了死锁状态。当出现死锁以后，有两种策略：

1、直接进入等待，直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout来设置。
2、发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on，表示开启这个逻辑。

在InnoDB中，innodb_lock_wait_timeout的默认值是50s，意味着如果采用第一个策略，当出现死锁以后，第一个被锁住的线程要过50s才会超时退出，然后其他线程才有可能继续执行。对于在线服务来说，这个等待时间往往是无法接受的。

但是，我们又不可能直接把这个时间设置成一个很小的值，比如1s。这样当出现死锁的时候，确实很快就可以解开，但如果不是死锁，而是简单的锁等待呢？所以，超时时间设置太短的话，会出现很多误伤。

所以，正常情况下我们还是要采用第二种策略，即：主动死锁检测，而且innodb_deadlock_detect的默认值本身就是on。主动死锁检测在发生死锁的时候，是能够快速发现并进行处理的，但是它也是有额外负担的。

每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是O(n)的操作。假设有1000个并发线程要同时更新同一行，那么死锁检测操作就是100万这个量级的。虽然最终检测的结果是没有死锁，但是这期间要消耗大量的CPU资源。因此，你就会看到CPU利用率很高，但是每秒却执行不了几个事务。

问题的症结在于，死锁检测要耗费大量的CPU资源。

你可以考虑通过将一行改成逻辑上的多行来减少锁冲突。还是以影院账户为例，可以考虑放在多条记录上，比如10个记录，影院的账户总额等于这10个记录的值的总和。这样每次要给影院账户加金额的时候，随机选其中一条记录来加。这样每次冲突概率变成原来的1/10，可以减少锁等待个数，也就减少了死锁检测的CPU消耗。

这个方案看上去是无损的，但其实这类方案需要根据业务逻辑做详细设计。如果账户余额可能会减少，比如退票逻辑，那么这时候就需要考虑当一部分行记录变成0的时候，代码要有特殊处理。

小结

这篇文章聊了Mysql的三种锁粒度，全局锁，表锁，行锁。其中，全局锁和表锁都是 Mysql 层级的锁，而行锁是引擎层的锁。

全局锁，顾名思义，是将整个库锁住，什么情况下会将整个库加锁呢？当然是做整库备份的时候，备份的时候我们要求数据只读，因为不能出现在备份过程中数据在变化，所以，可以使用FTWRL命令来让整个库处于只读的状态。但这种方法，对于增删改以及DDL操作等是不支持的，会阻塞这些行为。那还有一种方式让整个库处于只读的状态，就是使用 mysqldump 的 –single-transaction参数，不仅可以让数据库处于只读的状态，而且还不影响其他增删改的一系列操作。何乐而不为，但使用这个工具的前提是，数据库的所有表都要支持 只读事务隔离级别，满足这个条件，才可以使用，否则，还是乖乖使用 FTWRL命令 来备份吧。

表级别的锁，分为两种：表锁和MDL锁。在还没有出现更细粒度的锁的时候，表锁是最常用的处理并发的方式，当然，如果有InnoDB引擎支持的行级锁，一般还是不使用表级锁的。锁的粒度越小，并发度越高。其中，MDL锁分为读锁和写锁，而读锁之间不影响的，读锁与写锁，写锁与写锁是互斥的，需要等一个执行完另一个才能执行。

行锁，不是所有的引擎都支持行级锁，像 MyISAM 引擎就不支持行级锁，这也是为什么 InnoDB 替代 MyISAM 的主要原因之一。行锁，就一个概念是两阶段锁，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。还一个概念是，死锁与死锁检测，出现死锁后，会有两种策略，一种是等待超时，另一种是，检测机制发现有死锁时，就回滚死锁链条中的某一个事务，让其他事务得以执行。当然第二种策略是比较合理的，但也有一些问题，比如：如果所有的事务都要进行死锁检测，死锁检测这个动作要耗费大量的CPU资源。文中提到了一个将一行改成逻辑上的多行来减少锁冲突的方案。但需要做详细的设计，还需要做一些特殊处理。