MySQL学习笔记二：全局锁、表锁、MDL锁、行锁

     数据库锁设计的初衷是处理并发问题。作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。根据加锁的范围，MySQL 里面的锁大致可以分成全局锁、表级锁和行锁三类。

全局锁

全局锁就是对整个数据库实例加锁。可以通过命令 Flush tables with read lock (FTWRL) 对全局进行加锁，让整个库处于只读状态。

使用全局锁后，其他线程的以下语句会被阻塞：

• 数据更新语句（增删改）
• 数据定义语句（包括建表，修改表结构等）
• 更新类事务的提交语句。

全局锁的典型使用场景是，做全库逻辑备份。但如果直接用 FTWRL 去进行备份，会让整库都处于只读状态，这光想想就觉得危险。

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

那么不加锁备份数据库可以吗？答案是不可以的，比如你有两张表，余额表和商品表。如果不加锁，在备份期间时先备份余额表，再备份商品表会出现什么情况呢？假设在这两张表备份的间隔时间内进行了数据更新，则余额表数据在备份表中没有减少，但是商品表在备份表中的数据却减少了，造成了逻辑上的数据不一致问题。当然这两张表的备份顺序颠倒过来也是一样会有这个问题。

也就是说，不加锁的话，备份系统备份的得到的库表锁一个逻辑时间点，这个视图是逻辑不一致的。

       其实，在可重复读隔离级别下开启一个事务，也能够拿到一致性视图。

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

　　至此，为什么有了上述这个功能，还需要 FTWRL 呢？此处有个细节是：可重复读是很好，但并不是所有的MySQL引擎支持这个隔离级别的。（如 MyISAM 这种不支持事务的引擎，就需要执行 FTWRL 命令了。）所以，single-transaction方法只适用于所有的表使用事务引擎的库。如果有的表使用了不支持事务的引擎，那么备份就只能通过FTWRL的方法。

　　既然要保证备份时全库只读，为什么不使用 set global readonly = true 的方式呢？

不建议使用这种方式有以下两方面原因：

• 在有些系统中，readonly 的值会被用来处理其他逻辑，修改 global 变量的方式影响面更大。
• 在异常处理机制上的差异。执行 FTWRL 命令后如果客户端发生异常断开连接，那么 MySQL 会自动释放这个全局锁。而readonly=true 会保持数据库长时间处于只读状态。如果客户端发生异常，数据库一直保持 readonly 状态，这样会导致整个