MySQL schema 设计中的陷阱
虽然有一些普遍的好或坏的设计原则但也有一些问题是由MySQL 的实现机制导致的这意味着有可能犯一些只在MySQL 下发生的特定错误本节我们讨论设计MySQL 的schema 的问题这也许会帮助你避免这些错误并且选择在MySQL 特定实现下工作得更好的替代方案
太多的列
MySQL 的存储引擎API 工作时需要在服务器层和存储引擎层之间通过行缓沖格式拷贝数据然后在服务器层将缓沖内容解码成各个列从行缓沖中将编码过的列转换成行数据结构的操作代价是非常高的MyISAM 的定长行结构实际上与服务器层的行结构正好匹配所以不需要转换然而MyISAM 的变长行结构和InnoDB 的行结构则总是需要转换转换的代价依赖于列的数量当我们研究一个CPU 占用非常高的案例时发现客户使用了非常宽的表（数千个字段）然而只有一小部分列会实际用到这时转换的代价就非常高如果计划使用数千个字段必须意识到服务器的性能运行特征会有一些不同
太多的关联
所谓的实体 属性 值（EAV）设计模式是一个常见的糟糕设计模式尤其是在MySQL 下不能靠谱地工作MySQL 限制了每个关联操作最多只能有 张表但是EAV 数据库需要许多自关联我们见过不少EAV 数据库最后超过了这个限制事实上在许多关联少于 张表的情况下解析和优化查询的代价也会成为MySQL的问题一个粗略的经验法则如果希望查询执行得快速且并发性好单个查询最好在 个表以内做关联
全能的枚举
注意防止过度使用枚举（ENUM）下面是我们见过的一个例子
如果这里真和假两种情况不会同时出现那么毫无疑问应该使用枚举列代替集合列
非此发明（Not Invent Here）的NULL
我们之前写了避免使用NULL 的好处并且建议尽可能地考虑替代方案即使需要存储一个事实上的空值到表中时也不一定非得使用NULL也许可以使用某个特殊值或者空字符串作为代替
但是遵循这个原则也不要走极端当确实需要表示未知值时也不要害怕使用NULL在一些场景中使用NULL 可能会比某个神奇常数更好从特定类型的值域中选择一个不可能的值例如用 代表一个未知的整数可能导致代码复杂很多并容易引入bug还可能会让事情变得一团糟处理NULL 确实不容易但有时候会比它的替代方案更好
返回目录高性能MySQL
编辑推荐
ASPNET MVC 框架揭秘
Oracle索引技术
ASP NET开发培训视频教程
数据仓库与数据挖掘培训视频教程
