业务新上了一个功能，在发布的过程中，系统报出了数据库死锁异常：
com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction死锁发生在一个事务中，事务对多个表进行了操作。在报错日志中，死锁发生在tableA与tableB。一开始怀疑此次发布的某个改动中对上面这两张表新增了select或update操作。将注意力用在排查这个问题上。排查后发现没有相关的变更，又猜测是否是由于更改造成并发请求进来，接口原来是有加分布式锁的，需求更改中缩小了分布式锁的粒度，确实是有可能造成并发请求。但很快又否定了，秒杀场景下的并发量尚且不会发生死锁，何况是这个接口？觉得问题应该别有所在。先回滚了需求后，联系dba执行了命令SHOW ENGINE INNODB STATUS将死锁日志拉取了出来：
从死锁日志可以看到事务（1）TRANSACTION尝试更新表A，等待表A的锁(1)WATING FOR THIS LOCK TO BE GRANTED.但此时另外一个事务（2）TRANSACTION已经持有了表A的锁：(2)HOLDS THE LOCK(S),同时也在等待表B的锁(2)WATING FOR THIS LOCK TO BE GRANTED. 情况可能如下所示：
事务（1） | 事务（2） |
持有表1的写锁，并更新了表1 | |
等待表1的写锁 | |
等待表2的写锁 |
由于事务2一直都获取不到表2的写锁，事务2无法提交，因此事务2持有的表1锁没有释放（在事务执行过程中，如果有加锁操作，这个锁需要等事务提交时释放），导致事务1一直在等待表1的写锁，从而最终导致死锁。那么表2的写锁被哪个事务持有了？有没有可能是事务1？也即是下面这种情况：
事务（1） | 事务（2） |
持有表2的写锁，并更新了表2 | |
持有表1的写锁，并更新了表1 | |
等待表1的写锁 | |
等待表2的写锁 |
由于更新的是同一个用户的同一行记录，这种情况可能在sql执行顺序不一致所导致，所以对比了需求变更前后的事务逻辑，果然发现了端倪：
变更前：
事务开始
「
更新表1
更新表2
」
事务提交变更后：
事务开始
「
更新表2
更新表1
」
事务提交在发布的过程中，有部分机器的代码处于变更前，有部分机器的代码处于变更后，最终导致了上述的死锁问题。此时原因已经明了，但是疑惑的是为什么死锁出现时马上就报错，不会进行等待？查阅文档发现：死锁检测开了后，发生死锁会立马回滚。死锁检测关闭，锁等待超时时间这个设置才会生效：
