MySQL schema设计中应避免的陷阱

• 太多的列

　　 MySQL 的存储引擎API 工作时需要在服务器层和存储引擎层之间通过行缓冲格式拷贝数据，然后在服务器层将缓冲内容解码成各个列。从行缓冲中将编码过的列转换成行数据结构的操作代价是非常高的。MyISAM 的定长行结构实际上与服务器层的行结构正好匹配，所以不需要转换。然而，MyISAM 的变长行结构和InnoDB 的行结构则总是需要转换。转换的代价依赖于列的数量。当我们研究一个CPU 占用非常高的案例时，发现客户使用了非常宽的表（数千个字段），然而只有一小部分列会实际用到，这时转换的代价就非常高。如果计划使用数千个字段，必须意识到服务器的性能运行特征会有一些不同。

• 太多的关联

        所谓的“实体- 属性- 值”（EAV）设计模式是一个常见的糟糕设计模式，尤其是在MySQL 下不能靠谱地工作。MySQL 限制了每个关联操作最多只能有61 张表，但是EAV 数据库需要许多自关联。我们见过不少EAV 数据库最后超过了这个限制。事实上在许多关联少于61 张表的情况下，解析和优化查询的代价也会成为MySQL的问题。一个粗略的经验法则，如果希望查询执行得快速且并发性好，单个查询最好在12 个表以内做关联。

• 全能的枚举
• 变相的枚举
• 非此发明的null

        之前写避免使用null的好处，并且建议尽可能考虑替代方案，即使需要存储一个事实上的"空值"到表中，也不一定非用NULL，也许考虑使用0、某个特殊值、或者空字符串作为替代

    具体情况具体对待