MySQL Schema设计

MySQL Schema设计中的陷阱

太多的列:MySQL的存储引擎API工作时需要在服务器层和存储引擎层之间通过行缓冲格式拷贝数据,然后在服务器层将缓冲内容解码成各个列。这个过程的代价是非常高的。MyISAM的定长列不需要转换,但是变长列和InnoDB的行结构总是需要转换。转换的代价就依赖于列的数量。当然这个太多的列只是针对于上千的列而言。一般情况下是不会出现的。

太多的关联:所谓的“实体-属性-值”设计模式是一个常见的糟糕的设计模式。MySQL的关联操作最多只能允许61张表。即使在少于61张表也会带来很大的负担。如果希望查询速度快并且并发性好,单个查询最好在12个表以内做关联。

滥用枚举

范式和反范式

完全的范式和反范式都是在实验室才有的东西。在实际应用中都要根据实际情况混用。可能使用部分范式化的schema、缓存表。

最常见的反范式化数据就是复制或者缓存,在不同表中存储相同的列等。

缓存表和汇总表

有时候提升性能最好的方法是在同一张表中保存衍生的冗余数据。

以一个网站为例,假设要计算之前24小时内发送的消息数。在一个很繁忙的网站不可能维护一个实时精准的计数器。作为替代方案,可以定义一张汇总表,每小时统计一次发送消息数(或者每十分钟),插入到汇总表中,这样也许很简单的查询就能做到统计操作了,并且要比实时维护计数器要高效很多。缺点就是计数器并不是100%精确。

计数器表

如果应用在表中保存计数器,则在更新计数器时可能遇到并发问题。计数器表在web应用中很常见。可以用这种表存储一个用户的朋友数,文件下载数,点击量统计等等,计数器表都能很好的提高性能和简化操作