锁
MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类
全局锁
顾名思义，全局锁就是对整个数据库实例加锁
MySQL提供了一个加全局读锁的方法，命令是Flush tables with read lock(FTWRL)
当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞
数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句
全局锁的典型使用场景是，做全库逻辑备份。也就是把整库每个表都select出来存成文本
以前有一种做法，是通过FTWRL确保不会有其他线程对数据库做更新，然后对整个库做备份。注意，在备份过程中整个库完全处于只读状态
但是让整库都只读，听上去就很危险
- 如果你在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆
- 如果你在从库上备份，那么备份期间从库不能执行主库同步过来的binlog，会导致主从延迟
备份一定要加锁吗？我们先看一下不加锁会有什么问题
假设你现在要维护一个在线课程购买系统，关注的是用户账户余额表和用户课程表
现在发起一个逻辑备份。假设备份期间，有一个用户，他购买了一门课程，业务逻辑里就要扣掉他的余额，然后往已购课程里面加上一门课
如果时间顺序上是先备份账户余额表(u_account)，然后用户购买，然后备份用户课程表(u_course)，会怎么样呢？如下图：
不过现在基本都使用InnoDB存储引擎，可以使用一致性视图（可重复读）来实现数据备份
当mysqldump使用参数–single-transaction的时候，导数据之前就会启动一个事务，来确保拿到一致性视图。而由于MVCC的支持，这个过程中数据是可以正常更新的
其实，还有另外种方式实现全库只读，命令是set global readonly=true，但是还是更推荐使用FTWRL方式
- 在有些系统中，readonly的值会被用来做其他逻辑，比如用来判断一个库是主库还是备库
- 在异常处理机制上有差异。如果执行FTWRL命令之后由于客户端发生异常断开，那么MySQL会自动释放这个全局锁，整个库回到可以正常更新的状态
- 而将整个库设置为readonly之后，如果客户端发生异常，则数据库就会一直保持readonly状态，这样会导致整个库长时间处于不可写状态，风险较高
业务的更新不只是增删改数据（DML)，还有可能是加字段等修改表结构的操作（DDL）。不论是哪种方法，一个库被全局锁上以后，你要对里面任何一个表做加字段操作，都是会被锁住的
但是，即使没有被全局锁住，加字段也不是就能一帆风顺的，因为你还会碰到接下来我们要介绍的表级锁
表锁
MySQL里面表级别的锁有两种：一种是表锁，一种是元数据锁（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都不允许，自然也不能访问其他表
即：t1设置了读锁，t2设置了写锁，则其他人只能读t1，不能操作t2。本人能操作t2，但是其他人能读t1，所以
MDL不需要显式使用，在访问一个表的时候会被自动加上。MDL的作用是，保证读写的正确性
如果一个查询正在遍历一个表中的数据，而执行期间另一个线程对这个表结构做变更，删了一列，那么查询线程拿到的结果跟表结构对不上，肯定是不行的
因此，在MySQL5.5版本中引入了MDL，当对一个表做增删改查操作的时候，加MDL读锁；当要对表做结构变更操作的时候，加MDL写锁
读锁之间不互斥，因此你可以有多个线程同时对一张表增删改查。读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性
因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行
给一个表加字段，或者修改字段，或者加索引，需要扫描全表的数据。在对大表操作的时候，肯定会特别小心，以免对线上服务造成影响
而实际上，即使是小表，操作不慎也会出问题。我们来看一下下面的操作序列，假设表t是一个小表
我们可以看到sessionA先启动，这时候会对表t加一个MDL读锁。由于sessionB需要的也是MDL读锁，因此可以正常执行
之后sessionC会被blocked，是因为sessionA的MDL读锁还没有释放，而sessionC需要MDL写锁，因此只能被阻塞
如果只有sessionC自己被阻塞还没什么关系，但是之后所有要在表t上新申请MDL读锁的请求也会被sessionC阻塞
所有对表的增删改查操作都需要先申请MDL读锁，就都被锁住，等于这个表现在完全不可读写了
如果某个表上的查询语句频繁，而且客户端有重试机制，也就是说超时后会再起一个新session再请求的话，这个库的线程很快就会爆满
事务中的MDL锁，在语句执行开始时申请，但是语句结束后并不会马上释放，而会等到整个事务提交后再释放
那么，如何安全地给小表加字段？
首先我们要解决长事务，事务不提交，就会一直占着MDL锁。在MySQL的information_schema库的innodb_trx表中，你可以查到当前执行中的事务
如果你要做DDL变更的表刚好有长事务在执行，要考虑先暂停DDL，或者kill掉这个长事务
但考虑一下这个场景。如果你要变更的表是一个热点表，虽然数据量不大，但是上面的请求很频繁，而你不得不加个字段，你该怎么做呢？
这时候kill可能未必管用，因为新的请求马上就来了。比较理想的机制是，在alter table语句里面设定等待时间
如果在这个指定的等待时间里面能够拿到MDL写锁最好，拿不到也不要阻塞后面的业务语句，先放弃。之后开发人员或者DBA再通过重试命令重复这个过程
ALTER TABLE tbl_name NOWAIT add column ...
ALTER TABLE tbl_name WAIT N add column ...
行锁
MySQL的行锁是在引擎层由各个引擎自己实现的。但并不是所有的引擎都支持行锁，比如MyISAM引擎就不支持行锁
不支持行锁意味着并发控制只能使用表锁，对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行，这就会影响到业务并发度
InnoDB是支持行锁的，这也是MyISAM被InnoDB替代的重要原因之一
顾名思义，行锁就是针对数据表中行记录的锁。这很好理解，比如事务A更新了一行，而这时候事务B也要更新同一行，则必须等事务A的操作完成后才能进行更新
当然，数据库中还有一些没那么一目了然的概念和设计，这些概念如果理解和使用不当，容易导致程序出现非预期行为，比如两阶段锁
在上面的操作序列中，事务B的update语句执行时会是什么现象呢？假设字段id是表t的主键
这个问题的结论取决于事务A在执行完两条update语句后，持有哪些锁，以及在什么时候释放
实际上事务B的update语句会被阻塞，直到事务A执行commit之后，事务B才能继续执行
事务A持有的两个记录的行锁，都是在commit的时候才释放的
也就是说，在InnoDB事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议
所以我们在使用事务过程中，尽量把最可能造成锁冲突、最可能影响并发度的锁往后放，如下场景：
假设你负责实现一个电影票在线交易业务，顾客A要在影院B购买电影票
我们简化一点，这个业务需要涉及到以下操作
- 从顾客A账户余额中扣除电影票价
- 给影院B的账户余额增加这张电影票价
- 记录一条交易日志
最有可能产生锁冲突的是操作2，所以我们尽可能把操作2放到最后，即：3、1、2或1、3、2都是合理的
死锁和死锁检测
当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁
这时候，事务A在等待事务B释放id=2的行锁，而事务B在等待事务A释放id=1的行锁
事务A和事务B在互相等待对方的资源释放，就是进入了死锁状态
通常有2种策略来应对死锁：
- 设置参数innodb_lock_wait_timeout
- 发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on，表示开启这个逻辑
在InnoDB中，innodb_lock_wait_timeout的默认值是50s，意味着如果采用第一个策略，当出现死锁以后，第一个被锁住的线程要过50s才会超时退出，然后其他线程才有可能继续执行
对于在线服务来说，这个等待时间往往是无法接受的。但是，我们又不可能直接把这个时间设置成一个很小的值，比如1s。这样当出现死锁的时候，确实很快就可以解开，但如果不是死锁，而是简单的锁等待呢
所以，超时时间设置太短的话，会出现很多误伤
所以，正常情况下我们还是要采用第二种策略，即：主动死锁检测，而且innodb_deadlock_detect的默认值本身就是on
主动死锁检测在发生死锁的时候，是能够快速发现并进行处理的，但是它也是有额外负担的
你可以想象一下这个过程：每当一个事务被锁的时候，就要看看它所依赖的线程有没有被别人锁住，如此循环，最后判断是否出现了循环等待，也就是死锁
那如果是我们上面说到的所有事务都要更新同一行的场景呢？每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是O(n)的操作
假设有1000个并发线程要同时更新同一行，那么死锁检测操作就是100万这个量级的
虽然最终检测的结果是没有死锁，但是这期间要消耗大量的CPU资源。因此，你就会看到CPU利用率很高，但是每秒却执行不了几个事务
根据上面的分析，我们来讨论一下，怎么解决由这种热点行更新导致的性能问题呢？问题的症结在于，死锁检测要耗费大量的CPU资源
一种头痛医头的方法，就是如果你能确保这个业务一定不会出现死锁，可以临时把死锁检测关掉
但是这种操作本身带有一定的风险，因为业务设计的时候一般不会把死锁当做一个严重错误
毕竟出现死锁了，就回滚，然后通过业务重试一般就没问题了，这是业务无损的。而关掉死锁检测意味着可能会出现大量的超时，这是业务有损的
另一个思路是控制并发度。我们可以借助redis、队列等对接口进行限流，比如同一行同时最多只有10个线程在更新，那么死锁检测的成本很低，就不会出现这个问题
还有个思路就是将一行改成逻辑上的多行来减少锁冲突，但是这样会使得业务逻辑变得更为复杂
还是以影院账户为例，可以考虑放在多条记录上，比如10个记录，影院的账户总额等于这10个记录的值的总和
这样每次要给影院账户加金额的时候，随机选其中一条记录来加。这样每次冲突概率变成原来的1/10，可以减少锁等待个数，也就减少了死锁检测的CPU消耗
但是账户余额也有可能会减少，比如退票逻辑，那么这时候就需要考虑当一部分行记录变成0的时候，代码要有特殊处理