MySQL 死锁问题：它实际只能“并发读，单线程写入”？

以前从未意识到这个问题，我一直以为 MySQL 在多线程数据同步问题上不需要使用者过多的考虑，内部有那么多机制能保证多线程下数据一致问题。最近在深挖 MySQL 的锁知识的时候，发现了这一段，官网描述：
https://dev.mysql.com/doc/refman/5.7/en/innodb-locks-set.html

1 个表，存在唯一索引(主键索引也算唯一索引)。先让 1 个 session 去插入唯一索引所在列，然后 hold 在那里即不回滚，也不提交。此时另外启动两个 session，也插入同样的列值；这两个 session 为了检测唯一索引是否已经存在，会去申请共享锁，但由于此时第一个 session 持有互斥锁，会让后两个 session 申请共享锁的行为阻塞。2 和 3 的 session 就会等在那里；此时 1 的 session 回滚，释放掉互斥锁，2 和 3 的 session 会同时获得共享锁；他们要进一步获得互斥锁才能进行插入，但是，因为互斥锁和共享锁是冲突的，会形成，2 为了得到互斥锁必须等待 3 释放共享锁和 3 为了得到互斥锁也必须等待 2 释放共享锁的死锁现象，直到死锁超时回滚

我随便搜了一下发现这种死锁其实非常常见，网上有不少，在高一点的并发下 insert 就会出现死锁的情况。从原理上说，不需要 3 个 session，理论上，只要两个线程只要同时拿到共享锁就一定会发生死锁，

然而 mysql 官方并不认为这是个 bug。而我查到的解决办法居然是：在程序层上并发写变队列写（单线程写）。我总觉得这有点不合乎道理，有没有人聊聊其它家的数据库有解决方案吗，MySQL 的解决方法真的只有并发写变队列写这一条路了？

PS：如果关系数据库在写入上有这样的限制，我可不可以认为关系数据库实际是偏向“写少读多”场景的?

ziding

2018-11-07 16:20:47 +08:00

MySQL 我不确定，但是一个正规的关系数据库，连这个冲突都处理不了那就太 SB 了。回到问题中：锁是可以升级的，就你的例子中，2 和 3 会有一个获得写锁，而不是两个互傻等。数据库层面的死锁一般是由于写操作顺序不一致导致的，比如：
session1 update A -> update B

ziding

2018-11-07 16:21:13 +08:00

MySQL 我不确定，但是一个正规的关系数据库，连这个冲突都处理不了那就太 SB 了。回到问题中：锁是可以升级的，就你的例子中，2 和 3 会有一个获得写锁，而不是两个互傻等。数据库层面的死锁一般是由于写操作顺序不一致导致的，比如：
session1 update A -> update B
session2 update B -> update A

abcbuzhiming

2018-11-07 16:48:05 +08:00

@xiaoxinshiwo 没错啊，就是有唯一索引导致，实际开发中唯一索引很常见
@ziding MySQL 貌似就是处理不了，因为 1 个 session 要写和更新，需要获得排他锁，而排他锁和所有锁互斥，所以需要所有 session 都不持有锁，我说的案例里，两个 session 都持有共享锁，都去申请排他锁，他们都需要对方先释放掉共享锁，才能得到排他锁。所以就等在那死锁了。虽然说 MySQL 自己有死锁检测和处理，但是这个方式真的有点 2，而且 mysql 不认为这是 bug，它就是这么设计的