1 前言
MySQL的行锁是在引擎层实现：
- MyISAM不支持行锁，其并发控制只能用表锁，对于这种引擎的表，同一张表上任何时刻只能有一个更新在执行，影响业务并发度
- InnoDB支持行锁的，这是MyISAM被InnoDB替代的重要原因
行锁就是针对数据表中行记录的锁。事务A更新了一行，而这时候事务B也要更新同一行，须等事务A操作完成后才能更新。
事务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的update语句会被阻塞，直到事务A执行commit后，事务B才能执行。
事务A持有的两个记录的行锁，都在commit时才释放。 InnoDB事务中，行锁在需要时才加，等事务结束时才释放。
这就是两阶段锁协议。若你的事务中要锁多行，要把最可能造成锁冲突、最可能影响并发度的锁尽量往后放。
2 案例
顾客A要在影院B购买电影票：
- 从顾客A账户余额中扣除电影票价
- 给影院B的账户余额增加这张电影票价
- 记录一条交易日志
要完成交易，需update两条记录，insert一条记录。为保证交易原子性，要把三操作放在一个事务。
2.1 三语句在事务中的顺序
若同时顾客C在影院B买票，这两事务冲突部分就是语句2。因为它们要更新同一个影院账户的余额，要修改同一行数据。
两阶段锁协议下，不论怎样安排语句顺序，所有操作需要的行锁都在事务提交时才释放。 所以，若把2排在最后，如3、1、2，则影院账户余额这行锁的时间就最少。最大程度减少事务之间的锁等待，提升并发度。
但这并未完全解决问题。影院大促预售一年内所有电影票，只做一天。于是活动开始时，你的MySQL就挂了。登上服务器，CPU消耗近100%，但整个DB每秒执行不到100个事务，why？
2 死锁和死锁检测
当并发系统的不同线程出现循环资源依赖，涉及线程都在等待其它线程释放资源，就会导致这些线程都无限等待，造成死锁。
事务 1 | 事务 2 |
|---|---|
begin update t set k=k 1 where id=1; | begin; |
pdate t set k=k 1 where id=2; | |
update t set k=k 1 where id=2; | |
update t set k=k 1 where id=1; |
- 事务1在等待事务2释放
id=2的行锁 - 事务2在等待事务1释放
id=1的行锁 - 事务1和事务2在互相等待对方的资源释放，导致死锁
3 死锁后的策略
3.1 超时等待
通过参数 innodb_lock_wait_timeout 设置。
InnoDB的innodb_lock_wait_timeout默认50s，若采用策略1，死锁后，第一个被锁住的线程要50s才超时退出，然后其他线程才可能继续。对在线服务，这等待时间无法接受！
但也不可能直接把这时间设成一个小值。这样当死锁时，确实很快解开，但若不是因为死锁，而只是正常的锁等待呢？所以，超时时间设太短，会痛击友军。
3.2 主动死锁检测
发现死锁后，主动回滚死锁链中的某一事务，让其他事务继续执行。 将参数 innodb_deadlock_detect 设置为on，开启该逻辑。
正常情况采用该策略，而 innodb_deadlock_detect 默认on。
主动死锁检测在发生死锁时，能快速发现并处理，但有
3.2.1 额外负担
每当一个事务被锁，就看它所依赖线程是否被别人锁住。如此循环，最后判断是否出现循环等待，即死锁。
3.2.2 若所有事务都更新同一行数据？
每个新来的被堵住的线程，都要判断会不会由于自己的加入导致的死锁，时间复杂度O(n)。若有1000个并发线程要同时更新同一行，则死锁检测操作就是100万量级。虽最终检测结果是无死锁，但这期间消耗大量CPU。因此，你就会看到CPU占用率很高，但是每s却执行不了几个事务。
3.2.3 优化热点行更新
① 死锁检测关掉
死锁检测耗费大量CPU。若你能确保该业务一定不会出现死锁，可临时关闭死锁检测。但这有风险，因为业务设计时一般不会把死锁当严重错误：
- 毕竟出现死锁，就回滚，然后通过业务重试一般就没问题，业务无损
- 而关掉死锁检测意味着可能会出现大量超时，业务有损
② 控制并发度
若并发能够控制住，如同一行同时最多10个线程更新，则死锁检测成本低了，就不会出现这问题。
一个直接的想法，在客户端做并发控制。但很快发现这不太可行，因为客户端很多的！ 因此并发控制要做在DB服务端。若有中间件，可考虑在中间件实现。若团队有能修改MySQL源码的人，也可做在MySQL。
- 基本思路 对于同行更新，在进入引擎之前排队。这样在InnoDB内部就不会有大量死锁检测工作。若团队没有DB专家，不能实现这样方案，能否做设计优化？
③ 分段锁
考虑将一行改成逻辑上的多行，以减少锁冲突。
影院账户为例，可考虑放在多条记录，如10个记录，影院账户总额等于这10个记录值总和。这样每次给影院账户加金额时，随机选其中一条记录加。这样每次冲突概率变成原来1/10，减少锁等待个数，也就减少死锁检测的CPU消耗。
这看上去无损，但这类方案需按业务设计。若账户余额可能减少，如退票操作，就需考虑当一部分行记录变成0时，代码要有特殊处理。
4 总结
调整语句顺序不能完全避免死锁，以上方案都只是减少死锁对数据库影响。减少死锁的主要方向也就是控制访问相同资源的并发事务量。
