关于事务中死锁的一个问题

Question

各位大神，小弟在这里先祝大家新年快乐。

小弟最近遇到一个关于mysql事务的问题，由于技术底子太单薄，希望借助各位大神的力量解决一下。

问题描述：

现在有一个账户，该账户是为集成我们服务的第三方平台分配的，作用基本是用于扣款。

在账户表中有一个次数（账户金额）的一个字段，账户表使用的存储引擎为InnoDB。

第三方平台的终端用户在使用他们的某一项功能时（其实该功能时我们提供的），第三方平台来调我们的接口，然后我们就减一次上面说的那个次数（账户金额）。

其实，说白了就是减库存的问题。

第三方平台用户数量很多，可能会大量并发的过来使用该功能。

我方平台的这个接口，加了事务控制，使用的是spring4.3.2 + mybatis3.4.1

上面说了，账户表的存储引擎为InnoDB。所以，每次调用我们接口，我们在扣款的时候，应该是开启了行级锁，把该账户的这条数据锁住了。以后来的扣款，估计都在等待。

最近经常报出异常为：
Deadlock found when trying to get lock; try restarting transaction

我现在很疑惑，为什么是死锁？而不是等待锁超时呢？
如果为：Lock wait timeout exceeded; try restarting transaction
我想我可能会理解，但是Deadlock我就不解了。

因为，第一个扣款线程进来先锁住那行记录，第二第三...的扣款线程就在外面一直等着。
第一个线程提交事务，释放InnoDB行级锁，第二个线程进来获取锁...应该为这样的顺序。
mysql有一个等待锁的超时时间，如果超时，那么线程直接timeout。

这里应该不存在死锁的情况啊？我理解死锁应该为，多方牵制导致锁永远也释放不掉。
我这种情况不是释放不掉啊，线程提交或回滚就释放了的啊？

各位大神，帮忙解释解释这个问题吧，停基础的，但是小弟...不会...

Answer 1

数据库我也不是很了解，锁是很复杂的东西，你这里的情况可能涉及到当前读然后给上锁了。推荐一篇博客MySQL 加锁处理分析，看完了应该可以解惑吧。

Answer 2

https://dev.mysql.com/doc/ref...
应该和这个例子一个原因。

Answer 3

可以使用show innodb engine status看下，deadlock的具体信息。同时explan看下并发执行的语句会使用到的行数。