本文属于读书笔记,大部分内容摘抄于《高性能MYSQL》,摘抄内容版权属于原作者。
太多的列
mysql的存储引擎API工作时需要再服务器层和存储引擎层之间通过行缓冲格式拷贝数据,然后再服务器层将缓冲的内容解码成各个列。从行缓冲中将编码过的列转换成行数据结构的操作代价非常高。
太多的关联
所谓的“实体-属性-值”(EAV)设计模式是一个常见的糟糕的设计模式,尤其是在mysql下不能靠谱的工作。mysql限制了每个关联操作最多只能有61张彪。但是EAV数据库需要许多自关联。许多EAV数据库最后超过了这个限制。事实上即使在许多关联少于61张彪的情况下,解析和优化查询的代价也会成为mysql的问题。
一个粗略的经验法则,如果希望查询执行得快速并且并发性好,单个查询最好在12个表以内做关联。
全能的枚举
注意防止过度使用枚举。
在之前的学习中我们已经了解到,mysql数据库中,如果需要在枚举列表中增加一个新的国家时就要做一次ALTER TABLE操作,这种操作的花费对于大表来说是很难接受的。因此,尽量避免在不合适的情况下滥用枚举。
变相的枚举
枚举列允许在列中存储一组定义值中的单个值,集合SET列则允许在列中存储一组定义值中的多个值。有时候这可能比较容易导致混乱,
因为在有些情况下一组定义值中的某两个值可能是互斥的,不能同时出现,这种情况还是用枚举列比较恰当。
非此发明的NULL
因为我们已经在《选择优化数据类型的原则》这一节中学习了避免使用NULL的好处,那么建议尽可能的考虑替代方案。即使需要存储一个事实上的空值到表中,有些情况下也不是非得真的使用NULL,而可以用一些特殊值或者空字符串代替。
但是实际上也存在很多场景使用NULL会更好,在存储值的选择上我们不必走极端,例如用-1代替一个位置的整数,可能导致代码复杂很多,并且容易引入bug。所以这是一个不绝对的建议,按照实际情况选择合适的方法会更恰当。