MySQL锁分类
- 全局锁
- 表级锁
- 行锁
- 间隙锁
- next-key lock
全局锁
-
作用范围：对整个数据库实例加锁。(FTWRL)
flush tables with read lock;，该命令会让整个库处于只读状态，之后其他线程的以下语句会被阻塞：
1、数据更新语句(即对数据的增删改操作)。
2、数据定义语句(建表，修改表结构，加索引等操作)。
3、更新类事务的提交语句。
-
使用场景：全库逻辑备份。
-
备份加锁的必要性
如果不加锁，备份得到的库整体不是一个逻辑时间点，视图是逻辑不一致的。
-
缺点：
1、如果在主库上备份，整个备份期间都不能执行更新，业务基本上停摆。
2、如果在从库上备份，备份期间都不能执行从主库同步过来的binlog，会导致主从延迟。
-
mysqldump优点
官方自带的逻辑备份工具mysqldump，当使用参数-single-transaction时，导数据之前会启动一个事务，确保拿到一致性视图。由于MVCC的支持，在这个备份过程中数据是可以正常更新的。
-
FTWRL的必要性
mysqldump固然好，但是前提要引擎支持可重复读隔离级别，-single-transaction方法只是用于所有的表使用事务引擎的库。
-
FTWRL做备份优于set global readonly=true
1、某些系统中readonly值可能被用来做其他逻辑，比如判断一个库是master还是slave，修改global变量影响大。
2、在异常处理机制上。执行FTWRL后若是由于客户端发生异常，断开连接，MySQL会自动释放这个全局锁；set global readonly=true方式遇到这种情况会一直保持readonly状态，会导致整个库长时间不可写，风险高。
表级锁
- 表级锁包括表锁和元数据锁。
-
表锁
lock tables t1 read, t2 write;，此时，其他线程写t1，读写t2的语句都被阻塞。同时，在执行unlock tables前，本线程也只能对t1执行读操作，对t2执行读写操作；写t1的操作时不允许的，本线程也不能访问其他表。
-
使用场景：表锁通常用来处理并发。对于InnoDB这种支持行锁的引擎，一般不用表锁来控制并发。
-
元数据锁MDL(Meta Data Lock)
MDL不需要显示调用，在访问一个表时会自动加上，作用是保证读写的正确性。当对一个表做CRUD操作时，加MDL读锁；当对一个表结构变更操作时，加MDL写锁。
读锁之间不互斥，因此可以多个线程同时对一张表做CRUD操作；写锁之间，读写锁之间互斥，用来保证变更表结构操作的安全性，如果有2个线程同时对一个表做结构变更操作，其中一个要等另一个执行完才能执行。
MDL是系统默认加的，在一个事务中使用时，在语句执行开始时申请，但语句结束后并不会马上释放，要等整个事务提交后才释放。所以可能出现给一个小表加字段，导致整个库挂了的情况，如下：
start transaction; -- sessionA
select * from t limit 1; -- get MDL read and no release
start transaction; -- sessionB
alter table t add f int; -- waiting for session MDL read, blocked
行锁
- InnoDB行锁是通过给索引上的索引项加锁来实现的，意味着：只有通过索引条件检索数据，InnoDB才使用行级锁，否则，InnoDB将使用表锁。
- 行锁由MySQL各个引擎自己实现，并不是所有引擎都支持行锁，MyISAM就不支持行锁，InnoDB支持行锁，这里主要说InnoDB。
- 行锁分为读锁(S锁，共享锁)和写锁(X锁，排他锁)，对同一行的操作，只有读锁与读锁间不冲突。
-
两阶段锁协议：在InnoDB中，行锁是在需要的时候加上，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。
-
两阶段锁协议的影响：如果一个事务中需要锁多个行，要把最可能造成锁冲突，最可能影响并发度的锁尽量往后放。同理于MDL锁的释放，也就是说一个事务中的某一行的锁的持续时间，根据两阶段锁协议，如果事务提交的时间点确定，那么越早获得这一行的行锁，它的持续时间越长，所以对并发度影响大的行要尽量往后放。
-
死锁：两个事务互相等待对方的锁释放。
-
死锁应对策略
1、就是等，直到超时；超时时间可通过innodb_lock_wait_timeout设置，默认50s。（时间设置太长，很多在线服务无法接受；时间设置太短，可能产生很多非死锁的误伤）
2、主动发起死锁检测，发现死锁后，主动回滚死锁链条中的某一事务，让其他事务得以继续执行；参数innodb_deadlock_detect=on表示开启死锁检测。
-
主动检测死锁的过程：
每当一个事务要加行锁的时候，就要看看它所依赖的线程有没有被别人锁住（即需要看看自己需要的锁有没有在别人手里），如此循环，最后判断是否出现了循环等待，也就是死锁。
间隙锁
- 锁住索引树上相邻两个值之间的空隙。
-
间隙锁使用场景是RR(可重复读隔离级别)，也就是说它是InnoDB引擎所特有。
next-key lock
- 间隙锁和行锁合称next-key lock。以下是加锁规则。
-
原则1：加锁的基本单位是next-key lock，它是( , ]左开右闭区间。(除了“唯一索引的等值查询”，其他“范围查询”、“唯一索引范围查询”、“非唯一索引的等值查询”均要找到不满足条件的“整个区间”)。
-
原则2：查找过程中访问到的对象才会加锁。(若是涉及覆盖索引的查询，针对lock in share mode，若是所查询的字段都包含在覆盖索引中，那么不会锁主键索引；而for update 和 select 查找索引中没覆盖到的字段都会锁主键索引)。
-
优化1：唯一索引的等值查询，当找到符合条件的索引后，索引所在的间隙锁解除，该next-key lock退化为行锁。
-
优化2：索引上的等值查询(无论是否是唯一索引)，当向右遍历时且最后一个值不满足等值条件的时候，next-key lock退化为间隙锁。
-
补充1：唯一索引上的范围查询会访问到不满足条件的第一个值为止。
-
补充2：使用limit可以减小加锁范围，取到满足条件的语句条数，就结束。delete操作建议加上limit，一是保证安全性，二是减小加锁范围。
-
补充3：next-key lock加锁分为2步，先加间隙锁，再加行锁，间隙锁间不冲突(跟间隙锁存在冲突关系的，是“往这个间隙中插入一个记录”这个操作操作。)，行锁间冲突。这种锁的顺序可能产生死锁，A拿着B需要的行锁，B拿着A插入操作需要的间隙锁)。
