大并发下的mysql事务问题

现有如下场景：用户A和大量A 的粉丝，这时候A的粉丝不断的给A 送道具，这个道具是用户花钱买的，送给用户A之后，会给用户A 的帐号增加相应的钱，同时会给用户A 增加一些附件属性的值，比如用户A 的 经验值，血条长度啊，同时还会给该粉丝增加的经验值，那么这里涉及到的表有用户A 的钱的表，粉丝的钱的表，经验的表，那么我在处理这个时候 给整个过程加了事务处理，但是现在遇到的问题是：一旦有大量的用户同时给A送道具，那么就会出现数据库死锁的问题，请问这个该怎么处理？

回复内容：

现有如下场景：用户A和大量A 的粉丝，这时候A的粉丝不断的给A 送道具，这个道具是用户花钱买的，送给用户A之后，会给用户A 的帐号增加相应的钱，同时会给用户A 增加一些附件属性的值，比如用户A 的 经验值，血条长度啊，同时还会给该粉丝增加的经验值，那么这里涉及到的表有用户A 的钱的表，粉丝的钱的表，经验的表，那么我在处理这个时候 给整个过程加了事务处理，但是现在遇到的问题是：一旦有大量的用户同时给A送道具，那么就会出现数据库死锁的问题，请问这个该怎么处理？

这些行为,都不会要求即时返回结果,可异步化处理,关键词: 消息队列

死锁的问题在于程序或SQL代码有Bug。处理掉Bug，即使遇到再大的并发，最多是处理时间增大，但不会出现死锁。

检查一下sql语句中update .... where [conditon]，其中condition是否是主键？如果不是主键，在update时数据库会锁住整张表，多个线程同时操作时极容易出现死锁。
解决办法是，update 后的condition务必使用主键操作，此时数据库仅仅对当前操作记录使用行锁，不会死锁。

异步操作能满足你的需求。

Ps:某些操作是必须要求即刻返回数据的。比如用户消费买东西要先判断钱够不够。其实我是来推荐 PostgreSQL 的

同推荐PostgreSQL
异步队列是很好的解决方案