Mysql两阶段锁和死锁

两阶段锁

概念

讲的是InnoDB如何处理行锁的上锁，释放锁的行为。

在事务使用过程中，对记录以主键为条件删改时，会立刻加上排他锁，这完成了上锁阶段。

当删改动作完成后，这个锁并不会立即释放，需要等至事务提交时，才会释放锁。

引发的问题-阻塞

根据两阶段锁协议，事务 B将会因为id=1的数据被事务 A上了锁，而阻塞，因为事务 B需要拿到锁后才能进行下一步操作。

如何处理上述问题

我们应该尽量将可能会引起阻塞的语句，放到事务的最后面操作，例如上述事务 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最大连接数。

以上是对怎样减少行锁性能影响的学习总结。

这篇好文章是转载于：学新通技术网