**太多的列** mysql的存储引擎API工作时需要在服务器层和存储引擎层之间通过行缓存格式拷贝数据,然后在服务层将缓存内容解码成各个列.从行缓冲中将编码过的列转换成行数据结构的操作代价是非常高的 myisam的定长行结构实际上与服务层的行结构正好匹配,所以不需要转换.然而myisam的变长行结构和Innodb的行结构则总是需要转换.转换的代价依赖于列的数量 **太多的关联** 所谓的"实体-属性-值"(ENV)设计模式是一个常见的糟糕设计模式,尤其在mysql下不能靠谱的工作.mysql限制了每个关联操作最多只能有61张表,但是ENV数据库需要很多自关联. 事实上在许多关联少于61张表的情况下,解析和优化查询的代价也会成为mysql的问题 **全能的枚举** 注意防止过度使用枚举(ENUM) ~~~ create table ... ( country enum('','0','1','2',...'31') ~~~ 这种模式的表设计非常凌乱.这么使用枚举值类型也会在任何支持枚举类型的数据库都是一个有问题的设计方案,这里应该用整数作为外键关联到字典表或者查找表来查找具体值 但是在mysql中,当需要在枚举列表中增加一个新的国家时就要做一次ALTER TABLE操作,在mysql5.0以及更早的版本中ALTER TABLE是一个阻塞操作,即使在5.1和更新的版本中,如果不是在列表的末尾增加值也会一样需要ALTER TABLE **变相的枚举** 枚举(ENUM)列允许在列中存储一组定义值中的单个值,集合(SET)列则允许在列中存储一组定义值中的一个或多个值.有时候这可能比较容易导致混乱.这是一个例子 ~~~ create table ... ( is_default set('Y', 'N') NOT NULL default 'N' ~~~ 如果这里真和假两种情况不会同时出现,那么毫无疑问应该使用枚举列代替集合列 **非此发明的NULL** 写了避免使用NULL的好处,并且建议尽可能考虑替代方案 即使需要存储一个事实上的"空值"到表中,也不一定非得使用NULL.也许可以使用0,某个特殊值,或者空字符串作为代替 但是遵循这个原则也不要走极端.当确实需要表示未知值时也不要害怕使用null,在一些场景中,使用null可能会比某个神奇常数更好.从特定类型的值域中选择一个不可能的值.例如使用-1代表一个未知的整数,可能导致代码复杂很多,并容易引入bug,还可能会让事情变得一团糟.处理null确实不容易,但有时候会比他的替代方案更好 下面是我们经常看到的例子 ~~~ create table .. ( dt datetime not null default '0000-00-00 00:00:00' ~~~ 伪造的全0值可能导致很多问题(可以配置mysql的sql_mode来禁止不可能的日期,对于新应用这是个非常好的实践经验,它不会让创建的数据库里充满不可能的值).值得一提的是,mysql会在索引中存储NULL值,而Oracle则不会