探讨关于MySQL数据表的schena缺陷设计踩坑

我们在创建数据库时，基本都有一些普遍的好与坏的设计原则，但有些只有在MySQL中才会体现。这里会讨论一下MySQL的schema的问题，帮助我们避免这样错误。

1、太多的列

有些人使用非常宽的表（数千字段），然而只使用一小部分列，这时的转换代价就很高。由于MySQL的存储引擎API工作时需要在服务器层和数据层之间拷贝数据，然后在服务器层将缓存的内容解码成各个列。

我们应该经历的减少不必要的字段，比如一些预留字段。如果需要新的字段，我们可以新增就可以，不必刻意的去预留。

2、太多的关联

实体-属性-值（EAV）设计模式是一个糟糕的模式，尤其实在MySQL下不能靠谱的工作。MySQL限制每个关联操作最多只有61张表，但实际上在少于61张表下操作查询代价也是MySQL的问题。一些粗略的测试

得到，单查询最好在12张表以内做关联。

3、全能的枚举

枚举类型可以解决一些性能和错误的操作，但如果过度的是呀枚举会让schema的设计非常乱。所以我们应该经理的避免大量的使用枚举，对一些关键字段使用枚举就可以。

4、避免全部NULL

MySQL中我们应该尽量的避免NULL（空）的存储，就算存储实际上存储一个“空值”，我们也尽量的避免存储NULL，可以用其他的代替如 “0”，或者其他的特殊符号。

但我们也不必走向极端，对于一些未知值时也不要害怕的使用NULL。