极客时间--MySQL实战 45讲(6)(7) 数据库的锁

由于后续文章每一篇知识点并不会太多，而且几篇之间也相对连贯，因此之后将会几篇文章一起总结，算偷个小懒吧；

作为多用户共享的资源，当出现并发访问的时候，数据库需要合理地控制资源的访问规则。而锁就是用来实现这些访问规则的重要数据结构。根据加锁的范围，MySQL里面的锁大致可以分成全局锁、表级锁和行锁三类。

全局锁，就是对整个数据库实例加锁，MySQL提供一个命令，Flush tables with read lock(FTWRL)，使得整个库处于只读状态，数据更新、定义( 表结构的更改)相关的语句会被阻塞。一般用于全局逻辑备份，但是如此做是比较麻烦的。在有做主从分离的数据库中，在主库上操作，在此期间，不能执行更新，业务基本停摆。在从库上操作，将无法执行主库过来的binlog，导致主从延迟。
另外，有个参数也是可以使数据库处于只读状态，set global readonly=true。但是这个参数一般会有其他用途，比如用来区分主库从库，因此此命令一般不使用。

MySQL中的表级锁，一种是表锁，一种是元数据锁(meta data lock,MDL)，使用lock tables …read/write，对表进行加锁，使用unlock tables解锁，或者客户端断开连接时自动释放锁。
MDL不需要显式使用，访问表的时候会自动加上。其作用是，保证读写的正确性；

0.读锁之间不互斥，因此你可以有多个线程同时对一张表增删改查。
1.读写锁之间、写锁之间是互斥的，用来保证变更表结构操作的安全性。因此，如果有两个线程要同时给一个表加字段，其中一个要等另一个执行完才能开始执行。

行锁则是InnoDB 支持的，其他引擎不一定支持。讲到行锁，比较重要的概念是两阶段锁，
在InnoDB事务中，行锁是在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。；这个特性，我们使用事务的时候需要注意，如果一个事务中，需要锁多行，尽量把最可能造成冲突的锁往后放，后面再申请；

比如有个业务，电影票的在线交易业务，需要执行三步：
0.从顾客A账户余额中扣除电影票价；
1.给影院B的账户余额增加这张电影票价；
2.记录一条交易日志。
三条执行语句都在同一个事务里面，顺序并不太重要。从实际业务出发，给影院账户增加余额这一步是并发量最高的，放到后面，可以使得该事务持有该锁的时间降到最少，最大程度的减少对其他事务的影响；

还有两个概念，是死锁和死锁检测。
死锁后的解决策略，两种：
0.一种策略是，直接进入等待，直到超时。这个超时时间可以通过参数innodb_lock_wait_timeout来设置。
1.另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数innodb_deadlock_detect设置为on，表示开启这个逻辑。
在InnoDB中，innodb_lock_wait_timeout的默认值是50s，意味着如果采用第一个策略，当出现死锁以后，第一个被锁住的线程要过50s才会超时退出，然后其他线程才有可能继续执行。
MySQL中，innodb_deadlock_detect的默认值是on；每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，在并发量高的时候，都需要进行判断，需要耗费大量的CPU资源，因此有时候可以监控到，CPU资源占用高，但是每秒执行的事务却很少，原因很可能就在此；
要怎么解决由这种热点行更新导致的性能问题呢？
0.如果你能确保这个业务一定不会出现死锁，可以临时把死锁检测关掉。当然这是风险较高的；
1.控制并发度，可以考虑结合中间件实现；
2.以上面影院购票为例，可以考虑将影院的余额分散，由一行分成多行，更新的时候随机更新一行，这样就可以把冲突降低；多行数据加起来才是该影院真正的余额，当然业务代码也需要做出相应的调整；

链接：https://pan.baidu.com/s/1oTiGQX2l0UAOH4yaqcN7hw
提取码：um54