MySql--锁

全局锁

全局锁就是对整个***数据库实例加锁***。MySQL提供了一个加全局读锁的方法，命令是***Flush tables with read lock***。当需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞：数据更新语句（数据的增删改）、数据定义语句（包括建表、修改表结构等）和更新类事务的提交语句

全局锁的典型使用场景是，做全库逻辑备份。也就是把整库每个表都select出来存成文本，但是让整个库都只读，可能出现以下问题：

如果在***主库上备份***，那么在备份期间都不能执行更新，业务停摆

如果在***从库上备份***，那么在备份期间***从库不能执行主库同步过来的binlog***，会导致***主从延迟***,在***可重复读***隔离级别下开启一个事务能够拿到***一致性视图***

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

既然要全库只读，为什么不使用set global readonly=true的方式？

在有些系统中，readonly的值会被用来做其他逻辑，比如用来判断***一个库是主库还是备库***。因此***修改global变量***的方式***影响面更大***

在异常处理机制上有差异。如果执行***Flush tables with read lock**命令之后由于客户端发生异常断开，那么MySQL会自动释放这个全局锁***，整个库回到可以正常更新的状态。而将整个库设置为readonly之后，如果客户端发生异常，则数据库会一直保持readonly状态，这样会导致整个库长时间处于不可写状态，风险较高。

表级锁

MySQL里面表级别的锁有两种：一种是***表锁***，一种是***元数据锁***（meta data lock，MDL）

表锁

表锁的语法是***lock tables … read/write***。可以用unlock tables主动释放锁，也可以在客户端断开的时候自动释放。lock tables语法除了会限制别的线程的读写外，也限定了本线程接下来的操作对象。

如果在某个线程A中执行lock tables t1 read,t2 wirte;这个语句，则其他线程写t1、读写t2的语句都会被阻塞（读写，读读互斥）。同时，线程A在执行unlock tables之前，也只能执行读t1、读写t2的操作。连写t1都不允许（自身读也排斥自身写，及其他）

MDL表锁

另一类表级锁是***MDL***。MDL不需要显式使用，在访问一个表的时候会被自动加上。MDL的作用是，保证读写的正确性。如果一个查询正在遍历一个表中的数据，而执行期间另一个线程对这个表结构做了变更，删了一列，那么查询线程拿到的结果跟表结构对不上，肯定不行。

在MySQL5.5版本引入了MDL，当对一个表做***增删改查***操作的时候，加MDL读锁；当要***对表做结构变更***操作的时候，加MDL写锁。

• 读锁之间不互斥，因此可以有多个线程同时对一张表增删改查
• 读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。因此，如果有两个线程要同时给一个表加字段，给一个表加字段，或者修改字段，或者加索引，其中一个要等另一个执行完才能开始执行。
  session A先启动，这时候会对表t加一个MDL读锁。由于session B需要的也是MDL读锁，因此可以正常执行。之后sesession C会被blocked（修改表结构），是因为session A的MDL读锁还没有释放，而session C需要MDL写锁，因此只能被阻塞。如果只有session C自己被阻塞还没什么关系，但是之后所有要在表t上新申请MDL读锁的请求也会被session C阻塞。所有对表的增删改查操作都需要先申请MDL读锁，就都被锁住，等于这个表现在完全不可读写了
  
  事务中的MDL锁，在语句执行开始时申请，但是语句结束后并不会马上释放，而会等到整个事务提交后再释放
  

如何安全地给小表加字段？

首先要解决长事务，事务不提交，就会一直占着DML锁。在MySQL的information_schema库的innodb_trx表中，可以查到当前执行的事务。如果要做DDL变更的表刚好有长事务在执行，要考虑先暂停DDL，或者kill掉这个长事务

如果要变更的表是一个热点表，虽然数据量不大，但是上面的请求很频繁，而又不得不加个字段，该怎么做？

在alter table语句里面**设定等待时间***，如果在这个指定的等待时间里面能够拿到MDL写锁最好***，拿不到也不要阻塞后面的业务语句，先放弃。之后再通过重试命令重复这个过程

行锁

行锁就是针对数据表中行记录的锁。比如事务A更新了一行，而这时候事务B也要更新同一行，则必须等事务A的操作完成后才能进行更新

两阶段锁协议

事务A持有的两个记录的行锁都是在commit的时候才释放的，事务B的update语句会被阻塞，直到事务A执行commit之后，事务B才能继续执行
在InnoDB事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议

实例

假设要实现一个电影票在线交易业务，顾客A要在影院B购买电影票。业务需要涉及到以下操作：
1.从顾客A账户余额中扣除电影票价
2.给影院B的账户余额增加钱
3.记录一条交易日志

为了保证交易的原子性，要把这三个操作放在一个事务中。如何安排这三个语句在事务中的顺序呢？
如果同时有另外一个顾客C要在影院B买票，那么这两个事务冲突的部分就是语句2了。因为它们要更新同一个影院账户的余额，需要修改同一行数据（行锁导致阻塞）。根据两阶段锁协议，所有的操作需要的行锁都是在事务提交的时候才释放的。所以，如果把语句2安排在最后，比如按照3、1、2这样的顺序，那么影院账户余额这一行的锁时间就最少。这就最大程度地减少了事务之间的锁等待，提升了并发度。

死锁和死锁检测

• 一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout（50s默认）来设置
• 另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on（默认），表示开启这个逻辑。

怎么解决由这种热点行更新导致的性能问题？

1.如果确保这个业务一定不会出现死锁，可以临时把死锁检测关掉
2.控制并发度
3.将一行改成逻辑上的多行来减少锁冲突。以影院账户为例，可以考虑放在多条记录上，比如10个记录，影院的账户总额等于这10个记录的值的总和。这样每次要给影院账户加金额的时候，随机选其中一条记录来加。这样每次冲突概率变成员原来的1/10，可以减少锁等待个数，也就减少了死锁检测的CPU消耗

慢SQL问题

第一类：查询长时间不返回

1）、等MDL锁
有其他事务持有写锁。
2）、等flush
flush语句，如果指定表t的话，代表的是只关闭表t；如果没有指定具体的表名，则表示关闭MySQL里所有打开的表
出现Waiting for table flush状态的可能情况是：有一个flush tables命令被别的语句堵住了，然后它有堵住了select语句
3）、等行锁
由于访问id=1这个记录时要加读锁，如果这时候已经有一个事务在这行记录上持有一个写锁，select语句就会被堵住

带***lock in share mode***的语句是***当前读***，因此会直***接读到1000001这个结果***，速度很快；而***select * from t where id=1这个语句是一致性读***，因此需要从1000001开始，依次执行undo log，执行了100万次以后，才将1这个结果返回

间隙锁

间隙锁（Gap Lock）是Innodb在可重复读提交下为了解决幻读问题时引入的锁机制