全局锁

全局锁就是对整个数据库加锁。当我们对数据库加了读锁之后，其他任何的请求都不能对数据库加写锁了，当我们对数据库加了写锁之后，后续其他任何的请求都不能对数据库加读锁和写锁了。

FTWRL

MySQL 提供了一个加全局读锁的方法，Flush tables with read lock (FTWRL)。当我们需要让整个库处于只读状态时，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句。

全局锁的使用场景

全局锁的使用场景：做全库的逻辑备份。逻辑备份也就是把整个库的每个表都 select 出来存成文本。也就是全局锁只有在进行主从备份数据或者导入导出数据的时候才会使用到。

那么为什么需要全局锁呢？

因为我们在做数据备份或者导入导出数据的时候，如果在这个期间还可以同时进行数据的增删改，那么就会出现数据不一致的问题。

以前有一种做法是通过上面提到的 FTWRL 确保在备份的时候不会有其他线程对数据库做更新，注意：这里备份过程中整个库都是完全处于只读状态。

因为全局锁是面向这个数据库的，所以加全局锁听起来很危险：

如果我们在主库上备份，在备份期间都不能执行更新，也就是基本上全部业务暂停。
如果我们在从库上备份，在备份期间主库同步过来的 binlog 从库都不能执行，也就是会导致主从延迟，数据不一致。

如何避免加锁

既然加全局锁影响这么大，我们能不能避免加锁呢？

通过上面的介绍，我们知道加锁是为了解决数据不一致问题。那么是不是只要我们能解决数据不一致的问题，就可以不用加全局锁了。有这样一个思路：如果我们在开始进行数据备份的时候，记录一个操作日志，备份过程中不加锁允许对数据库的增删改查，而在备份过程中，增删改查的操作记录都记到一个日志文件里，等我们备份完成后，再把这段时间日志文件里的操作都执行一遍。这样就能保证备份前后数据的一致性了。

总结，不加锁的话，备份得到数据和主数据不是一个逻辑时间点，这个视图是逻辑不一致的。如果保证逻辑时间点一致即逻辑视图一致就能保证数据一致，由此我们就想到了我们之前学过的事务隔离级别，可重复复读的隔离级别下开启一个事务就是一个一致性视图。

在 MySQL 的默认引擎 InnoDB 里有一个机制可以保证数据一致性。InnoDB 引擎中有数据快照版本的功能，这个功能叫 MVCC，因为 MVCC 保留了历史版本的快照，每个快照都对应一个事务版本号，而在我们本分数据的时候会申请一个失误版本号，在读取数据的时候，只需要读取比自己事务版本号小的数据即可。

–single-transaction 命令加锁

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

--single-transaction 参数的作用，设置事务的隔离级别为可重复读，即 REPEATABLE READ，这样能保证在一个事务中所有相同的查询读取到同样的数据，也就大概保证了在 dump 期间，如果其他 InnoDB 引擎的线程修改了表的数据并提交，对该 dump 线程的数据并无影响。

并且设置 WITH CONSISTENT SNAPSHOT 为快照级别。设想一下，如果只是可重复读，那么在事务开始时还没 dump 数据时，这时其他线程修改并提交了数据，那么这时第一次查询得到的结果是其他线程提交后的结果，而 WITH CONSISTENT SNAPSHOT 能够保证在事务开启的时候，第一次查询的结果就是事务开始时的数据 A，即使这时其他线程将其数据修改为 B，查的结果依然是 A。

single-transaction方法只适用于所有的表使用事务引擎的库。在 mysqldump 过程中，加了--single-transaction 就能保证 InnoDB 的数据是完全一致的，对于MyISAM这种不支持事务的引擎，如果备份过程中有更新，总是只能取到最新的数据，那么就破坏了备份的一致性。这时候就还是需要全局锁的，所以我们就还是需要使用 FTWRL 命令的。