1.前言
Mysql的行锁是在存储引擎上进行实现的，但并不是每种存储引擎都支持，比如Myisam引擎层由各个引擎自己实现的。但并不是所有的引擎都支持行锁。对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行，这就会影响到业务的发展。innodb是支持行锁的，这也是Myisam被innodb替代的重要的原因之一。
2.行锁
行锁就是针对数据表中行记录的锁，比如事务A更新了一行，而这时候事务B也要更新同一行，则必须等事务A的操作完成后才能进行更新。
3.两阶段锁
在下面的操作序列中，事务B的update语句执行时会是什么现象呢？假设字段id是表t的主键。
这个问题的结论取决于事务A在执行完两条update语句后，持有哪些锁，以及在什么时候释放，你可以验证一下：实际上事务B的update语句被阻塞，直到事务A执行commit之后，事务B才能继续执行。
也就是说，在innodb事务中，行锁在需要的时候才加上的，但并不是不需要了就立刻释放，而是要等到事务结束时才释放。这个就是两阶段锁协议。
知道了这个设定，对我们使用事务有什么帮助呢？那就是，如果你的事务中需要锁多个行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。
两阶段锁协议让我们知道怎样执行语句的先后顺序才能最小减少锁冲突的概率，比如说：
1.从顾客A账户余额中扣除电影票价
2.给影院B的账户余额增加这张电影票价
3.记录一条交易日志。
也就是要完成这个交易，我们需要update两天记录，和执行insert 一条记录。当然，为了保证交易的原子性，我们要把这三个操作放在一个事务中。正确的执行的顺序为：3 1 2 ，为什么这样做呢？因为2这条记录是给影院的账户余额增加电影票价。因此会放在最后，这就最大程度地减少了事务之间的锁等待，提升了并发度。
但是这并不能消除你的锁冲突，比如说电影做活动，于是在活动时间开始的时候，你的Mysql就挂了，你登上服务器一看，CPU消耗接近100%，但是整个数据库每秒就执行不到100个事务，这是什么原因呢？
这里，我就要说到死锁和死锁检测了。
4.死锁和死锁检测
当并发系统中不同线程出现循坏资源依赖，涉及的线程都在等待别的线程释放资源时，就会导致这几个线程都进入无限等待的状态，称为死锁。这里我用数据中的行锁举个例子。
这时候，事务A在等待事务B释放id=2的行锁，而事务B在等待事务A释放id=1的行锁，事务A和事务B在互相等待对方的资源释放，就是进入了死锁状态。当出现以后，有两种策略：
1.一种策略是，直接进入等待，直到超时，这个超时时间可以通过参数innodb_lock_wait_timeout来设置。
2.另一种策略是，发起死锁检测，发现死锁后，主动回滚死锁链条中的某一个事务，让其他事务得以继续执行，将参数innodb_deadlock_detect设置为on,表示开启这个逻辑。
在innodb中，innodb_lock_wait_timeout的默认值是50s,意味着如果采用第一个策略，当出现死锁以后，第一个被锁住的线程要过50s才会超时退出，然后其他线程才可能继续执行，对于在线服务来说，这个等待时间往往是无法接受的。
但是，我们又不可能直接把这个时间设置成一个很小的值，比如1s。这样当出现死锁的时候，确实很快就可以解开，但如果不是死锁，而是简单锁等待呢？所以，超时时间设置太短的话，会出现很多误伤。
所以，正常情况下我们还是采用第二种策略，即：主动死锁检测，而且innodb_deadlock_detect的默认值本身就是on。主动死锁检测在发生死锁的时候，是能快速发现并进行处理的，但是它也是有额外负担的。
你可以想像一下这个过程：每当一个是事务被锁的时候，就是看看它依赖的线程有没有被别人锁住，如此循坏，最后判断是否出现了循坏等待，也就是死锁。
那如果是我们上面说到的所有事务都要更新同一行的场景呢？
每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，这是一个时间复杂度是O(n）的操作，假设有1000个并发线程要同时更新同一行，那么死锁检测操作就是100万这个量级的。虽然最终检测的结果是没有死锁，但是这期间要消耗大量的CPU资源，因此，你就会看到CPU利用率很高，但是每秒却执行不了几个事务。
根据上面的分析，我们讨论一下，怎么解决由这种热点行更新导致性能问题呢？问题的症结在于，死锁检测要耗费大量的cpu资源。
一种头痛医头的方法，就是如果你能确保这个业务一定不会出现死锁，可以临时把死锁检测关掉
另一个思路是控制并发度
因此，这个并发控制要做在数据库服务端。如果你有中间件，可以考虑在中间件实现；如果你的团队有能修改 MySQL 源码的人，也可以做在 MySQL 里面。基本思路就是，对于相同行的更新，在进入引擎之前排队。这样在 InnoDB 内部就不会有大量的死锁检测工作了。