读mysql45讲-全局锁和表锁的简单的认识

全局锁

全局锁就是对整个数据库实例进行上锁，mysql提供了一个加全局读锁的命令：Flush tables with read lock (FTWRL)
当需要让整个库处于只读的状态的时候，可以使用整个命令，当执行了整个命令之后，有关写入操作都会被阻塞：
数据更新语句（数据的增删改）、数据定义语句（包括 建表、修改表结构等）和更新类事务的提交语句。

全局锁的使用背景经常是数据库需要进行备份，这个时候使用FTWRL命令让其他线程不能进行对数据库进行写入操作，这个时候整个库就处于只读状态。

如果备份的时候不进行上锁的结果：

在购买课程之前进行备份，但是只备份了A的account，就会将A的账户200备份，然后在购买完课程之后再进行备份course，
之后如果使用备份数据来还原数据库，就会导致A的account还是200，但是coures就会多了一门课；这是不对的。
如果先备份course，购买课程，再备份account，就会导致course还是null，但是account减少了。

所以如果备份的时候不加锁，就会导致备份数据得到的数据是有问题的。如果在进行备份操作的时候，开启事务，结束备份的时候，再提交完毕，就可以保证备份数据是正确的。

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

对于存储引擎是MylSAM这种不支持事务的引擎，就需要使用到FTWRL命令保证整个库在备份期间是只读的。
set global readonly=true s 的方式也可以实现让数据库只读，区别有两点：

• ，在有些系统中，readonly的值会被用来做其他逻辑，比如用来判断一个库是主库还是备 库。因此，修改global变量的方式影响面更大，不建议使用。
• 在异常处理机制上有差异。如果执行FTWRL命令之后由于客户端发生异常断开，那么 MySQL会自动释放这个全局锁，整个库回到可以正常更新的状态。而将整个库设置为 readonly之后，如果客户端发生异常，则数据库就会一直保持readonly状态，这样会导致整个 库长时间处于不可写状态，风险较高。

表级锁

表级锁有两种：一种是表锁；另一种是元数据锁(meta data lock，MDL)。

表锁的语法是 lock tables …read/write 。与FTWRL类似，可以用unlock tables主动释放锁， 也可以在客户端断开的时候自动释放。需要注意，lock tables语法除了会限制别的线程的读写 外，也限定了本线程接下来的操作对象。 举个例子, 如果在某个线程A中执行lock tables t1 read, t2 write; 这个语句，则其他线程写t1、读 写t2的语句都会被阻塞。同时，线程A在执行unlock tables之前，也只能执行读t1、读写t2的操 作。连写t1都不允许，自然也不能访问其他表。

另一类表级的锁是 另 MDL M （metadata lock) m 。MDL不需要显式使用，在访问一个表的时候会被 自动加上。
当在修改表结构的时候，新增字段或者修改字段，删除字段的时候，就会给表加一个MDL写锁,不让在这个时候写入数据；
当在修改数据的时候，新增数据或者更新数据，删除数据的时候，给表加上一个MDL读锁，等操作完成才可以读数据。

• 读锁之间不互斥，因此你可以有多个线程同时对一张表增删改查。
• 读锁和写锁之间、写锁和写锁之间是互斥的，用来保证变更表结构操作的安全性。因此，如果有两个线 程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。

给一个表加字段，或者修改字段，或者加索引，需要扫描全表的数据。

sessionA先启动，查询数据，然后sessionB启动，查询数据，接着sessionC启动，修改表结构，这个时候被阻塞了，就会导致sessionD也被阻塞了。
sessionC阻塞的操作可能是因为sessionA的读操作还没结束。因为读锁和写锁是互斥的，所以在sessionA的MDL读锁还没释放之前，sessionC是不会得到MDL写锁的。

如果这个表的查询语句很高频，并且客户端有重试机制，就是在查询超时之后再新起一个session再次查询，就会导致这个库的线程池爆满。所以在修改表结构或者是修改数据的时候，如果存在一个长事务，并且一直没有提交，就需要考虑是先kill掉事务还是暂停修改操作。