一.什么是行锁

• MySQL的行锁是在引擎层由各个引擎自己实现的。但并不是所有的引擎都支持行锁。比如MyISAM引擎就不支持行锁。不支持行锁意味着并发控制只能使用表锁。         
• 对于这种引擎的表。同一张表上的任何时刻都只能有一个更新再执行，这会影响到业务并发度
• InnoDB是支持行锁的。这也是MyISAM被InnoDB替代的重要原因之一。

通过减少锁冲突来提升业务并发度

行锁就是针对数据表中行记录的锁。

二.两阶段锁

比如事务A更新了一行，这时候事务B也要更新同一行，则必须等事务A的操作完成后才能进行更新。

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

如果你的事务中需要锁多个杭，就要把最可能造成锁冲突，最可能影响并发读的锁尽量往后放。

三.使用场景

实例:
        假设你实现一个电影票在线交易业务顾客A要在影院B购买电影票这个业务需要以下操作：

• 从顾客A 账户余额中扣除电影票价
• 给影院B的账户余额增加这个电影票价
• 记录一条交易日志

分析

• 要完成这个交易，我们需要update两条记录，并且insert 一条记录。
• 当然为了保证交易的原子性，我们需要把这三个操作放在一个事务中，我们怎么安排这三个语句在事务中的顺序呢？

解决

• 根据两阶段锁协议，不论你怎么样安排语句顺序，所有的操作需要的行锁都是在事务提交的时候才释放。
• 所以，如果你把语句2安排到最后，如果按照3,1,2的顺序，那么影院账户余额这一行的锁时间最少，这就最大成都减少了事务之间的锁等待，提升了并发度。

四.问题2

     如果这个影院做活动，可以低价预售一年内所有的电影票，而且这个活动只做一天。于是活动时间开始时候，你的Mysql就挂了，你登上服务器一看，CPU消耗接近百分之100

但整个数据库每秒就执行不到100个事务，这是什么原因呢？

死锁检测要耗费大量的CPU资源

五.死锁和死锁检测

     当并发系统中不同线程出现循环资源一来，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。

    

 

• 事务A在等待事务B释放id=2的行锁，而事务B在等待事务A释放id=1的行锁。事务A和事务B在互相等待对方的资源释放，就是进入了死锁状态，当出现死锁以后，有两种策略；
• 另一种策略时，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行。将参数 innodb_deadlock_detect设置为on，表示开启这个逻辑。

六.超时释放的策略缺点

• 在InnoDB 中，innoDB_lock_wait_timeout的默认值是50s，意味着如果采用第一个策略，当出现死锁以后，第一个呗锁住的线程要过50s才会超时退出
• 然后其他线程才有可能继续执行，对于在线服务来说，这个等待时间往往是无法接受的，
• 但是我们又不能设置为一个很小的值，如1s。当出现死锁时候，确实很快可以解开，但如果不是死锁，而是简单的锁等待，超时时间设置太短的话，就会出现很多误伤。

七.主动死锁检测

• 而且innoDB_deadlock_detect的默认值本身就是on。主动死锁检测在发生死锁的时候，是能够快速发现并进行处理的，但是他有额外的负担。
• 每当一个事务被锁的时候，就要看他所依赖的线程有没有被别人锁住，如此循环，最后判断是否出现了循环等待，也就是死锁。

场景问题:

所有事务都要更新同一行的场景

• 每个新来的被堵住的线程，都要判断会不会由于自己的加入导致死锁，这是一个时间复杂度是O(n)的操作
• 假设有1000个并发线程要同时更新同一行，那么死锁检测操作就是100w，虽然最终检测的结果是没有死锁，但是这期间要消耗大量CPU资源。因此你会看到CPU利用率很高，
• 但是每秒却执行不了几个事务

死锁检测要耗费大量的CPU资源

解决方案：

临时把死锁检测关掉

• 这种操作本身就带有一定风险，因此业务设计的时候一般不会将死锁当做一个严重的错误，毕竟出现了死锁，就回滚，这是业务无损的
• 关掉死锁检测意味着可能会出现大量的超时，这是业务有损的。   

思路是控制并发读

• 比如同一行同时最多只有10个线程在更新，那么死锁 检测的成本很低，就不会出现这个问题一个直接的想法就是，在客户端做并发控制