MySQL：锁

　　根据加锁的范围，MySQL的锁可以分为全局锁，表级锁和行锁。

1. 全局锁

　　一般用于全局逻辑备份操作；

1.1 FTWRL

　　MySQL提供了一个加全局读锁的方法。命令是：Flush tables with read lock（FTWRL），执行该命令以下语句会被阻塞：数据更新语句，数据定义语句和更新事务的提交语句。

　　优点：

　　　　1：适用于所有的引擎；

　　　　2：客户端执行命令后若发生异常断开，则自动释放锁；

1.2 mysqldump

　　MySQL自带的逻辑备份工具，当mysqldump使用参数 -single-transaction的时候，导数据前其启动一个事务来确保拿到一致性视图，因为MVCC的支持，这个过程中的数据也是可以正常更新的。

　　缺点：引擎必须支持这个隔离级别，InnoDB支持该级别；

1.3  readonly

　　通过设置参数 set global readonly = true，让全库进入只读状态

　　缺点：

　　　　1：在某些系统中，可能会通过该参数的值判断一个数据库是主库还是从库，修改该参数的方式影响较大，不建议使用；

　　　　2：客户端在 set global readonly = true 之后若发生异常，该锁不会释放，整个库将一直处于只读状态，风险较大；

2. 表级锁

　　表级锁有两种：一种是表锁，一种是元数据锁（meta data lock，MDL）。

2.1 表锁

　　加锁语法：lock tables [table1] read,[table2] write;，该语句执行后,：

　　当前线程可以读 table1，不能写 table1，其他线程可以读 table1，不能写 table1；

　　当前线程可以读写 table2，其他线程不可以读写 table2；

　　当前线程不可以访问其他表；

　　解锁语法：unlock tables; ，该操作会释放所有表锁；

2.2  MDL

2.2.1 作用

　　MDL不需要显示使用，访问一个表时自动加MDL锁。它的作用是：在读写期间，保证表结构的一致性；

2.2.2 读锁和写锁

　　读锁之间不互斥，多个线程可以同时对一个表进行增删改查；

　　读锁和写锁，写锁和写锁之间互斥，保证修改表结构操作的安全性；

　　假设事务A查询记录，事务B修改表结构，事务C查询记录；

　　当事务B获取到表的MDL写锁后，在事务B提交之前，事务B 之后的所有事务都需要进行等待；

　　MDL锁会直到事务提交才释放，做表结构变更的时候一定不能阻塞线程的增删改查操作；

2.2.3 等待机制

　　理想的机制是修改表结构时设置等待时间，在等待时间内获取到MDL锁则进行操作，否则放弃操作；

　　MariaDB 支持该功能：

　　alter table table_name  nowait add ...;

　　alter table table_name wait  n add ...;

3. 行锁

　　行锁由引擎层实现，并不是所有的引擎都支持行锁，InnoDB支持行锁。

　　在InnoDB的事务中，行锁在需要时进行加锁，事务结束后释放锁。这就是两阶段锁协议。

　　如果事务需要多个行锁，则尽可能将可能导致锁冲突的锁往后放；减少冲突锁的等待时间。

3.2 死锁和死锁检测

　　假设有两个事务同时进行，事务A要先修改记录1，再修改记录2，事务B要先修改记录2，再修改记录1；

　　当两个事务各自完成第一个操作后，都开始等待对方释放锁，这就形成了一个死锁；

　　解决死锁的策略：

　　1. 直接进入等待，直到超时。超时时间可通过 innodb_innodb_lock_wait_timeout 参数来设置，默认值为50；

　　　超时时间设置过长业务一般无法接受，时间过短又容易出现误伤，一般采用第二种方案，即死锁检测，

　　2. 发起死锁检测，发现死锁后，主动回滚死锁链条中的某个事务，让其他事务继续执行，死锁检测可通过 innodb_deadlock_detect 参数设置为 on 开启该功能，默认值为 on；

　　    死锁检测需要消耗CPU资源，如果某个时刻进行大量事务的死锁检测，这需要耗费大量的CPU资源，但是事务执行效率却很低；所以尽量控制这个并发数量；