数据库锁设计的初衷是处理并发问题。作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。锁就是起到这样的作用。
根据加锁的范围，MySQL 里面的锁大致可以分成全局锁、表级锁和行锁三类。
一. 全局锁
全局锁其实就是对整个数据库实例加锁，MySQL 提供了2种加全局读锁的方法：
- Flush tables with read lock (FTWRL)
- set global readonly=true
相同点
一个库被全局锁上以后，数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句都会被阻塞。
不同点
1. 在有些系统中，readonly 的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库。因此，修改 global 变量的方式影响面更大，所以不建议使用该种方式。
2. 在异常处理机制上有差异。如果执行 FTWRL 命令后，客户端发生异常断开，那么MySQL 会自动释放这个全局锁，整个库回到可以正常更新的状态。
而将整个库设置为 readonly 之后，如果客户端发生异常，则数据库就会一直保持 readonly 状态，这样会导致整个库长时间处于不可写状态，风险较高。
典型使用场景
全局锁的典型使用场景是，做全库逻辑备份。也就是把整库每个表都 select 出来存成文本，在备份过程中整个库完全处于只读状态。
实际上这样做是存在一定风险的：
- 如果在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆；
- 如果在从库上备份，那么备份期间从库不能执行主库同步过来的 binlog，会导致主从延迟。
那么如果我们不加全局锁的话，会发生什么问题呢？
假如现在有两张表，账单表和余额表，如果用户购买商品后生成了账单，但是余额还未扣除的时间点上进行了备份，这样会破坏数据的一致性。也就是说，备份系统备份的得到的库不是一个逻辑时间点，这个视图是逻辑不一致的。
实际上，官方自带的逻辑备份工具： mysqldump是可以解决这个问题的，当 mysqldump 使用参数 –single-transaction 的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于 MVCC 的支持，这个过程中数据是可以正常更新的。
既然有了这个功能，为什么还需要 FTWRL 呢？一致性读是好，但前提是引擎要支持这个隔离级别。比如，MyISAM 这种不支持事务的引擎，如果备份过程中有更新，总是只能取到最新的数据，那么就破坏了备份的一致性。这时，我们就需要使用 FTWRL 命令了。
所以，single-transaction 方法只适用于所有的表使用事务引擎的库。如果有的表使用了不支持事务的引擎，那么备份就只能通过 FTWRL 方法。这往往是 DBA 要求业务开发人员使用InnoDB 替代 MyISAM 的原因之一。
二. 表级锁
MySQL 里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL)。
1.表锁
表锁用于用于为单个表加锁，表锁的类型分为读锁和写锁。
加表锁的命令：
lock tables … read/write
释放表锁的命令：
unlock tables
表锁对线程的阻塞作用：
lock tables 语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。
比如线程A对表加表锁后：
- 不能对没有加锁的表执行DML和DDL语句；
- 对加了read表锁的表只能进行读操作；
- 对加了write表锁的表能进行读写操作；
在线程A没有释放表所前，对于后续的线程B：
- 无法读写线程A加了write表锁的表；
- 可读但无法写线程A加了read表锁的表；
- 可读写没有加表锁的表；
2.元数据锁 MDL（metadata lock)
MySQL5.5版本引入了MDL锁（metadata lock），当对一个表做增删改查操作的时候，加 MDL读锁；当要对表做结构变更操作的时候，加 MDL 写锁。MDL 不需要显式使用，在访问一个表的时候会被自动加上。
读锁之间不互斥，因此你可以有多个线程同时对一张表增删改查。读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。
考虑到MDL的互斥性，添加字段的时候就需要异常的小心，比如下面的操作序列就会造成大面积的阻塞：
session A 先启动，这时候会对表 t 加一个 MDL 读锁。由于 session B 需要的也是 MDL 读锁，因此可以正常执行。
之后 session C 会被 blocked，是因为 session A 的 MDL 读锁还没有释放，而 session C 需要 MDL 写锁，因此只能被阻塞。
之后所有要在表 t 上新申请 MDL 读锁的请求都会被 session C 阻塞，也就是说，所有对表的增删改查这些需要先申请MDL 读锁的操作，就都被锁住了，等于这个表现在完全不可读写了。
如果某个表上的查询语句频繁，而且客户端有重试机制，也就是说超时后会再起一个新 session 再请求的话，这个库的线程很快就会爆满。
为了解决这个问题，我们可以考虑暂停 DDL，或者 kill 掉这个长事务。
而对于一个不得不添加字段而请求又很频繁的表，我们可以在 alter table 语句里面设定等待时间，如果在这个指定的等待时间里面能够拿到 MDL 写锁就进行修改；拿不到也不要阻塞后面的业务语句，先放弃，之后再通过重试命令重复这个过程。
ALTER TABLE tbl_name WAIT N add column ...
三. 行锁
行锁就是针对数据表中行记录的锁。比如事务 A 更新了一行，而这时候事务 B 也要更新同一行，则必须等事务 A 的操作完成后才能进行更新。
1. 两阶段锁协议
在 InnoDB 事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是 两阶段锁协议。
所以如果事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。这样加锁时间最少，能够最大程度地减少事务之间的锁等待，从而提升了并发度。
虽然这样能够降低锁冲突发生的概率，但是并不代表完全不会出问题，当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁 。
2. 死锁和死锁检测
以下是一个死锁的模拟场景：
此时，事务 A 在等待事务 B 释放 id=2 的行锁，而事务 B 在等待事务 A 释放 id=1 的行锁。 事务 A 和事务 B 在互相等待对方的资源释放，就是进入了死锁状态。
这个问题有两种解决策略：
- 直接进入等待，直到超时。超时时间可以通过参数 innodb_lock_wait_timeout 来设置。在 InnoDB 中，innodb_lock_wait_timeout 的默认值是 50s，意味着出现死锁后，第一个被锁住的线程要过 50s 才会超时退出，然后其他线程才有可能继续执行。
- 发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect 设置为 on，表示开启这个逻辑。这个参数的默认值是 on，主动死锁检测在发生死锁的时候，能够快速发现并处理，但是死锁检测本身会耗费大量的 CPU 资源。
如果能够确保业务一定不会发生死锁，也可以选择关掉死锁检测。但是这种操作本身带有一定的风险，我们可以采用另外一种思路，就是控制访问相同资源的并发事务量来减少死锁。这个就需要根据具体的业务逻辑来进行优化，比如通过将一行改成逻辑上的多行来减少锁冲突，以此来减少锁等待个数，也就减少了死锁检测的 CPU 消耗。