嬲嬲嬲嬲嬲嬲嬲嬲613
两阶段锁
概念
讲的是innodb如何处理行锁的上锁，释放锁的行为。
在事务使用过程中，对记录以主键为条件删改时，会立刻加上排他锁，这完成了上锁阶段。
当删改动作完成后，这个锁并不会立即释放，需要等至事务提交时，才会释放锁。
引发的问题-阻塞
| 事务 a | 事务 b |
|---|---|
| begin; update t set k=k 1 where id=1; update t set k=k 1 where id=2; | |
| begin; update t set k=k 2 where id=1; | |
| commit; |
根据两阶段锁协议，事务 b将会因为id=1的数据被事务 a上了锁，而阻塞，因为事务 b需要拿到锁后才能进行下一步操作。
上述这个问题，可能看似问题不大，但是如果不止是事务 b，还有事务 c，事务 d，等等很多，做的是跟事务 b一样的事，问题就大了，被阻塞的线程就会多了起来。【推荐学习：mysql视频教程】
如何处理上述问题
我们应该尽量将可能会引起阻塞的语句，放到事务的最后面操作，例如上述事务 a例子中的id=1的语句，它和第二句的执行并没有什么关联关系，可是它是容易引起阻塞的语句，因为在事务 b中也要对这一行数据做锁操作（在各类事务中频繁使用的，如公司的收付款账号余额记录，即**热点行**），但是却在事务一开始就拿到锁了。
本质上，是缩短了拿锁时间和释放锁之间的时间。即持有锁的时间缩短，以此减少锁引起的阻塞。
死锁
概念
两个线程，互相在等待对方释放资源。
在两个事务a，b中。
事务 a拿到了资源 a的锁。事务 b拿到了资源 b的锁。事务 a去拿资源 b的锁。事务 b去拿资源 a的锁。
很明显，步骤 3，4中，事务 a，b 都想去拿锁，但是又都拿不到，因为对方都还没有释放该资源的锁。这种现象就是死锁。
引发的问题-死锁
在innodb中，有一个拿锁的等待时间配置，超过这个时间就会抛出异常，这个时间默认是50秒。通常来说，有一个接口需要50秒后才响应是不可接受的。innodb_lock_wait_timeout。
那是不是把这个配置时间设置短一点就行了？比如1秒？
应该是不可以的，因为可能会影响到你的正常业务，或许你的业务导致你的事务执行时间本身就比较长，超过1秒。超出这个时间会抛出异常，你的正常业务就被影响了。
那该如何处理上述问题
在innodb中，还有一个自动检测死锁并处理的配置。它是默认开启的，在极端情况下，虽然能处理问题，但是对cpu消耗特别大。
它原理是在事务中即将要上锁的时候，会去检测其他并发线程，有没有将此资源锁住，如果检测到某个线程a有，然后再会去检测线程a的依赖有没有被其他并发线程锁住，如此循环往复，最终判断这些锁会不会形成死锁。
可以看出，线程越多，检测成本就越大。innodb_deadlock_detect。
仅代表个人当前的学习做出的对此问题的处理和总结：
1.关闭死锁检测，将拿锁时间配置缩短至预估的最高时间，通常不会超过15秒，超过15秒后，需要有重试机制。
2.开启死锁检测，在应用层控制并发连接数，使用连接池控制mysql的连接数，在服务层限制mysql最大连接数。
以上是对怎样减少行锁性能影响的学习总结。
以上就是一起聊聊mysql两阶段锁和死锁的详细内容，更多请关注其它相关文章！
