mysql schema设计中应避免的陷阱

谨记红字：

1. 表中谨防太多列：

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

 

2. 太多关联：

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

 

3. 全能的枚举：