笔记记录自林晓斌（丁奇）老师的《MySQL实战45讲》
6） --全局锁和表锁：给表加个字段怎么有这么多阻碍
数据库锁设计的初衷是处理并发问题。作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要结构。根据加锁的范围，MySQL里面的锁大致可以分为全局锁，表级锁和行锁三类。这篇笔记主要包含全局锁和表级锁。行锁的内容会在之后再进行分享。
全局锁：
全局锁就是对整个数据库实例加锁。可以通过命令 Flush tables with read lock (FTWRL)对全局进行加锁。使用全局锁后，其他线程的以下语句会被阻塞：数据更新语句（增删改），数据定义语句（包括建表，修改表结构等）和更新类事务的提交语句。
全局锁的典型使用场景是，做全库逻辑备份。但如果你直接用上面的FTWRL去进行备份，会让整库都处于只读状态，这光想想就觉得危险。如果你在主库上备份，那么在备份期间都不能执行更新，业务基本停摆；如果你在从库上备份，那么备份期间从库不能执行从主库同步过来的binlog，会导致主从延迟。那么不加锁备份数据库可以吗？答案是不可以的，比如你有两张表，余额表和商品表。如果不加锁，在备份期间时先备份余额表，再备份商品表会出现什么情况呢？假设在这两张表备份的间隔时间内进行了数据更新，则余额表数据在备份表中没有减少，但是商品表在备份表中的数据却减少了，造成了逻辑上的数据不一致问题。当然这两张表的备份顺序颠倒过来也是一样会有这个问题。
官方自带的逻辑备份工具是mysqldump.当mysqldump使用参数-single-transaction时，备份数据之前会启动一个事务，来确保拿到一致性视图。而由于MVCC（多版本并发控制）的支持，这个过程中数据是可以正常更新的。
至此，你可能会有个疑问，为什么有了上述这个功能，还需要FTWRL呢？此处有个细节是 可重复读是很好，但并不是所有的MySQL引擎支持这个隔离级别的。（如MyISAM这种不支持事务的引擎，就需要执行FTWRL命令了。）所以，single-transaction方法只适用于所有的表使用事务引擎的库。
既然要保证备份时全库只读，为什么不使用set global readonly = true的方式呢？ 不建议使用这种方式有以下两方面原因：
- 在有些系统中，readonly的值会被用来处理其他逻辑。
- 在异常处理机制上的差异。FTWRL命令后如果客户端发生异常断开连接，那么MySQL会自动释放这个全局锁。而readonly=true会保持数据库长时间处于只读状态。
表级锁：
MySQL里面表级别的锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL）
表锁的语法是 lock tables ... read/write。与FTWRL类似，可以用unlock tables主动释放锁，也可以在客户端断开的时候自动释放。需要注意的是，lock tables语法除了会限制别的现成的读写外，也限定了本线程接下来的操作对象。在没有更细粒度的锁的时候，表锁是最常用的处理并发的方式。而对于InnoDB这种支持行锁的引擎，一般不使用lock tables命令来控制并发，毕竟锁住整个表的影响面还是太大。
另一类表级锁MDL不要显示使用，在访问一个表的时候会自动加上。它的作用是保证读写的正确性。如一个查询正在遍历一个表中的数据，而同时另一个线程对这个表结构做了变更，删了一列，那么查询线程拿到的结果就会和表结构对不上，肯定是不行的。因此，在MySQL5.5引入了MDL，当对一个表做增删改查操作的时候，加MDL读锁；当要对表结构变更时，加MDL写锁。
- 读锁之间不互斥，因此可以有多个线程同时对一张表增删改查。
- 读写锁之间，写锁之间是互斥的。以此来保证变更表结构操作的安全性。因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。
另外，MDL会知道事务提交才释放，在做表结构变更的时候，一定要小心不要导致锁住线上查询和更新。
表级锁一般是在数据库引擎不支持行锁的时候才会被用到。如果你发现你的应用程序里有lock tables这样的语句，你需要追查一下，比较可能的情况是：
- 你的系统还在使用MyISAM这类不支持事务的引擎，需要安排升级更换引擎了
- 你的引擎升级了，但是代码还没有升级。这样把lock tables和unlock tables更换成begin和commit，问题就解决了。
上篇问题答案：
表结构如下所示：
CREATE TABLE `geek` ( `a` int(11) NOT NULL, `b` int(11) NOT NULL, `c` int(11) NOT NULL, `d` int(11) NOT NULL, PRIMARY KEY (`a`,`b`), KEY `c` (`c`), KEY `ca` (`c`,`a`), KEY `cb` (`c`,`b`) ) ENGINE=InnoDB;
由于历史原因， a和b需要做联合主键。那么既然主键包括了a,b这两个字段，又单独在c上创建了一个索引，索引就已经包含了三个字段了，为什么还要创建ca，cb索引呢？有人给出的理由是业务里有这样两个查询：
select * from geek where c=N order by a limit 1; select * from geek where c=N order by b limit 1;
这个理由对吗？为了这两个查询，这两个索引是否都必须呢？为什么呢？
我们以一组记录来回答这个问题。
| a | b | c | d |
| 1 | 2 | 3 | d |
| 1 | 3 | 2 | d |
| 1 | 4 | 3 | d |
| 2 | 1 | 3 | d |
| 2 | 2 | 2 | d |
| 2 | 3 | 4 | d |
主键a,b的聚簇索引组织顺序相当于order by a,b。也就是先按a排序，再按b排序，c无序。
索引ca的组织顺序如下（先按c排序，再按a排序），同时记录主键部分b的值
| c | a | b |
| 2 | 1 | 3 |
| 2 | 2 | 2 |
| 3 | 1 | 2 |
| 3 | 1 | 4 |
| 3 | 2 | 1 |
| 4 | 2 | 3 |
你可能会发现，ca的组织顺序和索引c的顺序是一模一样的。
索引cb的组织顺序如下（先按c排序，再按b排序，同时记录主键a）
| c | b | a |
| 2 | 2 | 2 |
| 2 | 3 | 1 |
| 3 | 1 | 2 |
| 3 | 2 | 1 |
| 3 | 4 | 1 |
| 4 | 3 | 2 |
所以，结论是ca可以去掉，cb索引仍要保留。ca去掉的原因是组织顺序与索引c相比完全相同。
问题：
备份一般都会在备库上执行，你在用-single-transaction方法做逻辑备份的过程中，如果主库上的一个小表做了一个DDL，比如给一个表上加了一列。这时候，从备库上会看到什么现象呢？