死锁和死锁检测
当并发系统不同线程出现循环资源依赖，涉及的线程都在等待别的线程释放资源，就会导致这几线程都无限等待=》死锁。
- 事务1在等待事务2释放
id=2的行锁 - 事务2在等待事务1释放
id=1的行锁 - 事务1和事务2在互相等待对方的资源释放，导致死锁
死锁后的策略
超时等待
该超时时间可通过参数innodb_lock_wait_timeout设置。
InnoDB中，innodb_lock_wait_timeout默认值50s，若采用策略1，当死锁后，第一个被锁住的线程要50s才超时退出，然后其他线程才可能继续。对在线服务，这等待时间无法接受！
也不可能直接把这时间设成一个小值。这样当死锁时，确实很快解开，但若不是因为死锁，而只是正常的锁等待呢？所以，超时时间设太短，会误伤友军。
主动死锁检测
发现死锁后，主动回滚死锁链中的某一事务，让其他事务继续执行。
将参数innodb_deadlock_detect设置为on，开启该逻辑。
正常情况采用该策略，而且innodb_deadlock_detect默认值就是on。
主动死锁检测在发生死锁时，能够快速发现并处理，但有额外负担：
每当一个事务被锁，就看看它所依赖的线程是否被别人锁住。如此循环，最后判断是否出现循环等待，即死锁。
- 若是说到的所有事务都更新同一行数据？
每个新来的被堵住的线程，都要判断会不会由于自己的加入导致了死锁，时间复杂度O(n)。若有1000个并发线程要同时更新同一行，则死锁检测操作就是100万量级。虽然最终检测结果是没有死锁，但这期间要消耗大量CPU。因此，你就会看到CPU占用率很高，但是每秒却执行不了几个事务。
优化热点行更新
死锁检测关掉
问题在于，死锁检测耗费大量CPU资源。若你能确保该业务一定不会出现死锁，可以临时把死锁检测关掉。但这操作有一定风险，因为业务设计时一般不会把死锁当做一个严重错误：
- 毕竟出现死锁，就回滚，然后通过业务重试一般就没问题，业务无损
- 而关掉死锁检测意味着可能会出现大量超时，业务有损
控制并发度
如果并发能够控制住，比如同一行同时最多10个线程更新，那么死锁检测成本低了，就不会出现这问题。
一个直接的想法，在客户端做并发控制。但很快发现这不太可行，因为客户端很多的！！！
因此并发控制要做在数据库服务端。若有中间件，可考虑在中间件实现。若团队有能修改MySQL源码的人，也可做在MySQL。
基本思路
对于同行更新，在进入引擎之前排队。这样在InnoDB内部就不会有大量死锁检测工作。
若团队没有DB专家，不能实现这样方案，能否做设计优化？
分段锁
可以考虑将一行改成逻辑上的多行，以减少锁冲突。
以影院账户为例，可考虑放在多条记录，比如10个记录，影院的账户总额等于这10个记录值总和。这样每次给影院账户加金额时，随机选其中一条记录加。这样每次冲突概率变成原来1/10，减少锁等待个数，也就减少了死锁检测的CPU消耗。
这方案看上去无损，但这类方案需根据业务逻辑做详细设计。若账户余额可能减少，比如退票操作，则此时就需要考虑当一部分行记录变成0时，代码要有特殊处理。
调整语句顺序并不能完全避免死锁，以上方案都只是减少死锁对数据库影响。减少死锁的主要方向也就是控制访问相同资源的并发事务量。
