本篇文章给大家带来了关于mysql锁的相关知识，其中主要介绍了mysql 两阶段锁和死锁，下面一起来看一下，希望对大家有帮助。
两阶段锁
概念
讲的是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最大连接数。
以上是对怎样减少行锁性能影响的学习总结。
