为凡人默哀 与 怎么从开发人员的角度，来看表设计和优化

此篇的开始之前，默哀3分钟，某些伟大的凡人不是他位高权重，也不是他能一句话使整个世界停转，而是 陌生人 想起他，从心底为他的离去感到伤心，哪怕只有一秒。

What one does when he faced with truth is more difficult than you think.

十分抱歉本期没有彩色的图片，但希望这一个有温度的技术公众号

___________________________________________________________________________

怎么从开发人员的角度，来看表设计和优化

一个开发人员如果主动的来优化自己的查询，其实是一件不容易的事情，首先很多查询并不是开发人员自己写的，而是通过各种框架生成的语句.

所以这就造成了，优化语句的工作不在开发人员这一端，因为他们不知道实际上执行的语句是啥样子的，即使知道啥样子，实际上也很难来进行优化。

所以一般来说，他们需要对数据库捕捉后的语句的从慢到快的一个排列序列。通过这个序列，开发人员通过表的名字以及查询的结果，应该能很快的定位差不多的语句与模块之间的关系。

这样的方式的结果很可能是，对这个查询来分析是否缺少 INDEX ，或者语句的撰写是否有问题，将撰写的方式进行修改等等。实际上这样的方式仅仅能解决一部分问题，而将一部分问题掩藏，最终当数据变得更多的时候，问题可能再次出现，并且到时候在进行改变就很难了。

所以从开发人员的角度其实应该从以下方式来想以下问题

1 没有好的表设计，会为日后的问题埋下炸弹，数据库表设计是基础工作

2 表设计以及底层设计，会直接影响你后期的查询，数据写入

3 添加索引并不是解决问题的优选，或者出现问题的唯一解

4 差的表设计，将在数据量变大后，使得你上不去下不来，到时在进行表重新设计，将给程序的修改引起麻烦，甚至是导致部分模块重构。

在明白以上问题，开发人员优化语句的角度就会改变，不在仅仅以功能为主，而是从另一个角度来看待问题。

那说的容易，做的难，道理谁都懂，但怎么做

1 由于是框架来主导并生成语句，则表设计的时候，要考虑一个点，易读性也就是这个表最终对外提供的数据，是不是仅仅需要这一个表就能提供，还是需要几个表。

2 如果仅仅是需要这一个表提供数据，则这个表的数据量有多大，可以预估一下，一天大于多少，（不必要很准确，我经常听到的是，我也不知道数据量有多少，或者我不知道一天有多少数据量）其实我觉得听到这些声音的时候，让我有一种不大负责的感觉，因为一个表的使用者，或者设计者竟然不知道这个表要承载的数据，这不大让人能接受。（你自己都不清楚，你要别人怎么办）

3 如果是多表查询，则多表查询里面那些是基础表（因为多表查询或多或少符合了三范式），那些是业务表，或者哪里是记录表（流水账式的表）

4 根据上面 2 3 的问题，在各个击破，如果是单表，则要考虑是否有标有进行分区，或分库分表，在数据量较大的情况下，针对不同数据库的特点，以及架构进行，这时开发人员可能就需要介入 DBA 或者相关的人员来进行混合式的分析和相关的设定，专业的人做专业的事情。如果是多表的情况下，在分析出基础表，业务表，记录表等多种表是否需要混合查询后，会对表的设计进行重新规划，是否需要将数据进行冗余，避免太多表的关联，而数据的冗余就需要开发人员进行对程序的重新设计。

5 在设计时会有两种极端，1 将所有数据集中在一张表上，2 严格遵循三范式

这两种都不是好的设计，将所有数据都集中在一张表上，会让这张表变成热表，因为基础数据和业务数据在一起，无疑会将列数，行宽，以及行数都以倍数进行扩展。这样的结果就是，这张表会变得很大，并且锁会由于表访问的频度来增加，读失败和写失败的可能性，也就是我们俗称的锁。

而严格遵循三范式的表，在数据的DML 上将产生很多问题，在数据的写入时，是需要原子性的，如果将表拆的过散，则程序上会使用很多的锁，来保证数据到多个表的原子性，而这样的方式，也会产生，将数据写入一个表的产生的问题，产生大量的锁。

6无论是严格符合三范式，或者将表严格不符合三范式，都将产生的最终结果就是，表中的锁的增加，以及数据的访问和写入的困难增加。

举例，用户的地址信息

我们有以下设计方式

1 用户家庭地址，一个字段解决，内容是 XX省XX市XX镇XX路XX号XX层房间号

2 多个字段来解决

省市，市， 镇，村，路，号，层，门牌号

上面两种都不是好的设计方式，一个太粗，一个太细，直接导致的结果就是提取数据的时候，统计用户所在的省市有多少用户，这会遇到很多的麻烦，字符的分割，以及拼接，以及业务中各种应用场景，或者直接需要客户的详细地址。

好的方式可以是结合1 + 2 的方式，在表设计时，就将可以详细分类的省市，或者镇等信息分开存储，而在设计一个总体信息存储的字段。看上去这样会占用更多的存储空间，但一张表的信息的访问热度就会分散，统计会着重统计类的字段，省市，镇， 而功能性应用会去直接找到原始字段，进行输出。

当然还有另外一种方式的设计，就是将省市，镇单独存在一张表并给她们定义编码，而实际应用的时候，非功能+功能表 的方式来输出。这样的设计也有好处，就是大量的缩小的数据的存储空间，加速了提取数据的速度，试想我是对文字进行过滤快，还是对数字过滤快，对内存的占用低，对内存占用的低，则更有效的利用CPU，降低I/O交互。

当然这样的设计也是有缺点的，就是增加了表之间的 关联性，将单表访问变成多表访问，实际上我们只要变化思路，这样的方式还可以进行优化，当然需要更多的数据库的进入，各分其责。

其实表设计，牵扯的到的事情很多，甚至包括了硬件的部分，一个好的系统的设计是缺少不了，表的设计，以及相关架构的设计，而不好的设计，将让你的系统后期的维护成本和故障率都越来越高。

所以设计表时是要符合三范式还是不严格遵守三范式，根据业务逻辑大部分情况可能会选择后者。

注：什么是三范式

1F 指定表中的每个单元格只能有一个值，而不能有值列表.

2F 要求每个属性都必须完全依赖于整个主键。这意味着每个属性应该直接依赖于主键，而不是通过其他属性间接地依赖于主键。

3F 规则增加了一个要求，即每个非键列独立于每个其他列。如果在一个非键列中更改一个值会导致另一个值更改，则该表不符合第三种范式