MySQL锁

MySQL中的锁大致可以分为全局锁、表级锁、行锁

全局锁

加全局锁的命令：Flush tables with read lock
全局锁主要的使用场景就是全局备份。
例如下图如果不加全局锁的话,会存在如下问题：
购买课程的操作，如果数据库是先备份余额表然后此时用户购买，然后数据库再备份用户课程表的话，就会出现我没有花钱但是多了一门课程的情况。

也就是说，如果不加锁的话，备份系统备份的得到的库不是一个逻辑时间点，这个视图是逻辑不一致的。

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

表级锁

mysql中表级锁分两种：1.表锁 2.元数据锁(MDL)
表锁的语句lock tables … read/write。可以用unlock table 释放锁，也可以在客户端断开的时候自动释放。
假如某个线程A中执行了lock tables t1 read, t2 write; 的话，其他线程写t1、读写t2都会阻塞。而线程A则只能读t1和读写t2.

另外一种表级锁MDL，MDL不需要显式使用，在访问一个表的时候会被自动加上。
MySQL5.5版本引入MDL，当对一个表做增删改查操作的时候，加MDL读锁；当对表结构变更操作的时候，加MDL写锁。
读锁之间不互斥，因此你可以有多个线程同时对一张表进行增删改查。
读写锁、写锁之间是互斥的，用来保证变更表结构操作的安全性。因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。
虽然MDL是自动加的，但却是一个你不能忽略的机制。比如下面这个例子：给一个小表加字段导致整个数据库挂了。
你肯定知道给一个小表加字段，或者修改字段或者加索引，需要扫描全表的数据。在对大表操作的时候，你一定要特别小心，以免出现线上问题。而实际上，小表操作不慎也会出现问题。
假设表t是一个小表，我们看到session A先启动这时候会对表t加一个MDL读锁。然后由于session B需要的也是读锁，所以能正常工作。但是session C会被阻塞，因为session C需要的是写锁。如果只有session C自己被阻塞还没什么关系，但是之后所有要在表t上新申请MDL读锁的请求也会被session C阻塞。前面我们说了，所有对表的增删改查操作都需要先申请MDL读锁，就都被锁住，等于这个表现在完全不可读写了。

如何安全的给小表加字段？
首先要解决的是长事务问题，事务不提交就会一直占用MDL锁。在MSYSQL的information_schema 库的 innodb_trx 表中，你可以查看到正在执行的事务。如果你要做DDL刚好有长事务操作，你可以先暂停DDL或者kill掉这个长事务。

行锁

mysql的行锁是在引擎层由各个引擎来实现的。并不是所有引擎都支持行锁的，比如MYISAM引擎就不支持行锁。不支持行锁就意味着每一个表此时只能有一个更新在执行，会严重影响业务发展。这也是为什么innodb取代myisam的原因。

两阶段锁

在innodb事务中，行锁是在需要的时候被加上的，但并不是不需要的时候就立即释放，而是要等到事务结束的时候才释放，这就是两阶段提交协议。
**所以如果事务中如果需要锁多行，要把最可能造成锁冲突的，最可能影响并发度的操作往后放。**例如一个事务有以下几个操作：
1.从顾客A账户余额中扣除电影票价；
2.给影院B的账户余额增加这张电影票价；
3.记录一条交易日志。

那么如果多个人同时买票，造成锁冲突的语句就是2，所以如果我们将顺序改为3、1、2。2执行的时候会被加上行锁，然后事务执行结束就会被释放。这就最大程度地减少了事务之间的锁等待，提升了并发度。

死锁和死锁检测

当并发系统中不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程出现无限等待的状态，称为死锁。
出现死锁后有两种策略：
1.直接进入等待直到超时，这个超时时间可以通过innodb_lock_wait_timeout来进行设置。
2.另一个策略发起死锁检测，发现死锁后，主动回滚死锁链条中的某一事务，让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on表示开启这一逻辑。

方法2虽然能快速发现并处理，但是它有额外的负担。你可以想象一下这个过程：每当一个事务被锁住，就要看看线程有没有被别人锁住。如此循环，最终判断是否出现循环等待，也就是死锁。
那如果是我们上面说到的所有事务都要更新同一行的场景呢？
每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是O(n)的操作。假设有1000个并发线程要同时更新同一行，那么死锁检测操作就是100万这个量级的。虽然最终检测的结果是没有死锁，但是这期间要消耗大量的CPU资源。因此，你就会看到CPU利用率很高，但是每秒却执行不了几个事务。

那怎么解决这种热点更新导致的性能问题呢？
1.如果你确保这个业务一定不会出现死锁，就临时把死锁检测关了。
2.控制并发度，基本思路就是，对于相同行的更新，在进入引擎之前排队。这样在InnoDB内部就不会有大量的死锁检测工作了。