前言
数据库设计锁的初衷是处理并发问题，作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。
根据加锁的范围，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资源。文中提到了一个将一行改成逻辑上的多行来减少锁冲突的方案。但需要做详细的设计，还需要做一些特殊处理。