表设计与死锁，及为什么MYSQL 的死锁比别的数据库少

最近公司业务系统中的死锁较多，比较担心，并且最近在群里面，经常听到有一些群友，提到为什么MYSQL的死锁监控上比较LOW，但还好的是MYSQL的死锁不是太多。这里触发了我关于死锁的一些看法，延伸到表设计，系统的设计。

首先，什么是死锁我觉得我就不在重复和婆婆妈妈了，如果还不知道什么是死锁，则还是先百度一下哈。

死锁在每个数据库系统中都会出现，并且死锁的出现比较容易出现在传统企业，或者业务复杂的，使用非MYSQL的数据库中（这里没有歧视，这里提到的死锁较少的MYSQL 是指互联网企业，非传统企业的MYSQL，或功能单一的容器化的MYSQL数据库）

主要的原因有几点

1 传统的系统的设计基本上是围绕着一个或几个核心表进行的查询和DML 操作完成的，而一般传统的系统在设计之初可能由于业务大小，和业务量上，开发设计核心表的初衷都比较简单，但随着业务的复杂度，或业务量的上涨，原先的核心表的设计就会产生瓶颈，试想如果是一个公司的核心人员，原理只负责 A 业务，后续由于业务扩展 B ,C ,D 业务都需要他来复制，并且还有是不是其他业务需要他来协调，或者询问他的开发，他在厉害，在同一个时刻也只能处理一个事件。其他的事件都的在wait的状态，而如果两个任务或多个任务同时都需要 他，则这几个事务就的打起来，最后谁更重要就占用这个核心的人员。

所以在系统的设计中，随着业务的扩展，可能就需要给这个核心的人员，找一个帮手，或者直接将他的功能分解， 必须我们可以给个核心的人员，找一个帮手。

说起来容易，做起来难，面临的第一个问题就是，核心表如果功能有重合的部分，则字段也有重合的地方，如何在一次输入将部分相同的数据放入到两张表或多张表，这是一个问题，是通过程序来做，还是通过其他的方式进行传递，如果是通过程序来做，将其变成一个事务好，还是通过类似MQ 的消息传递的方式好，或者用第三方的数据库表复制的方式。

所以一个系统随着越来越复杂，考验表设计人员，或者BDER的事情就多起来，这时如果DBER 还是重基础数据库知识，而没有业务或其他更广泛的知识，则你也只能听命于他人，起不到自己应该有的作用。

反过来，题目中为什么提到MYSQL的死锁少的问题

1 一般来说用MYSQL的企业大部分都是互联网企业，而互联网企业的业务相对传统行业，业务简单，并且互联网企业的技术人员的水平，相对传统企业来说要高。

2 用到MYSQL的企业部分核心的业务都在分库，或分表，通过分库和分表可以将这类问题进行一定的化解，降低表在提供信息时的耦合度，其实还是那句话，空间换了时间。

3 使用MYSQL 的系统大部分也在使用读写分离，这样的使用也有利于化解查询和DML 操作之间的问题，而死锁大部分的问题产生于这方面的影响。

所以这也是上面某些群里面的人员，提到了MYSQL的死锁为什么相对于其他数据库系统少的主要原因。

其实还有一个原因，有些互联网企业的DML 操作，不是通过简单的条件进行的DML ，而是根据主键进行DML 操作，在DML 操作之前要获取需要DML操作的主键，而在MYSQL的主键操作是很快的，具体原理这里也就不再提了，以免婆婆妈妈。

而其他数据库系统是否也可以，回答是，是的。

SQL SERVER Always on 是可以进行读写分离的，而 PG 更是天生就有这样的基因，各种数据的复制技术都是有的，基本上用在MYSQL上的技术在PG上进行读写分离都是OK 的。

这里不提ORACLE的原因，有2 ， 1 ORACLE 在buffer 内存设计上异同于其他数据库，2 使用ORACLE的数据库的表设计人员，比较传统，出现上边死锁的设计方式与传统的三范式以及传统的表设计方式有关，并且什么读写分离，主键操作，在ORACLE上都不大现实。因为ORACLE 这个数据库本身的设计思路就是单体扩容的思路，这本身就是造成瓶颈的原因。

其实讨论到表设计这个事情来说，一般初期是不会考虑的特别周到的，1 业务量，业务的清晰度，可能都达不到一个设计之初需要进行考虑的需求，2 本身非MYSQL的数据库功能上都能容纳一些不合理的设计和查询。

而正是因为这样，其他的数据库使用中随着时间的流逝，和业务的扩展，发生问题的几率都比 使用MYSQL的数据库的大。

终其原因，如果混乱的，不合理的使用MYSQL数据库，则还没到死锁爆发，数据库早就不干活了。