1.合理使用范式和反范式
1.1范式的优点
范式化的更新通常比反范式要快
当数据较好的范式化后,很少或者没有重复的数据
范式化的数据比较小,可以放在内存中,操作比较快
1.2范式的缺点
通常需要进行关联
1.3反范式的优点:
所有的数据都在同一张表中,可以避免关联
可以设计有效的索引;
1.4反范式的缺点:
表格内的冗余较多,删除数据时候会造成表有些有用的信息丢失
2.合理使用范式和反范式
在企业中很好能做到严格意义上的范式或者反范式,一般需要混合使用
另一个从父表冗余一些数据到子表的理由是排序的需要。
缓存衍生值也是有用的。如果需要显示每个用户发了多少消息(类似论坛的),可以每次执行一个昂贵的自查询来计算并显示它;也可以在user表中建一个num_messages列,每当用户发新消息时更新这个值。
在一个网站实例中,这个网站,允许用户发送消息,并且一些用户是付费用户。现在想查看付费用户最近的10条信息。 在user表和message表中都存储用户类型(account_type)而不用完全的反范式化。这避免了完全反范式化的插入和删除问题,因为即使没有消息的时候也绝不会丢失用户的信息。这样也不会把user_message表搞得太大,有利于高效地获取数据。
3.反范式的案例
以下是范式设计的表
以下是反范式设计的表
4.主键的选择
4.1代理主键
与业务无关的,无意义的数字序列(如id)
4.2自然主键
事物属性中的自然唯一标识(如身份证号码)
推荐使用代理主键:它们不与业务耦合,因此更容易维护
5.字符集的选择
1.纯拉丁字符能表示的内容,没必要选择 latin1 之外的其他字符编码,因为这会节省大量的存储空间。
2.如果我们可以确定不需要存放多种语言,就没必要非得使用UTF8或者其他UNICODE字符类型,这回造成大量的存储空间浪费,建议使用UTF-8MB4进行存储,因为Utf-8在存储中文的时候不一定是两个字符,当存进来的中文超过两个字符的时候就会出现乱码。
3.MySQL的数据类型可以精确到字段,所以当我们需要大型数据库中存放多字节数据的时候,可以通过对不同表不同字段使用不同的数据类型来较大程度减小数据存储量,进而降低 IO 操作次数并提高缓存命中率。
6.存储引擎的选择
7.适当的数据冗余
1.被频繁引用且只能通过 Join 2张(或者更多)大表的方式才能得到的独立小字段。
2.这样的场景由于每次Join仅仅只是为了取得某个小字段的值,Join到的记录又大,会造成大量不必要的 IO,完全可以通过空间换取时间的方式来优化。不过,冗余的同时需要确保数据的一致性不会遭到破坏,确保更新的同时冗余字段也被更新。
8.适当拆分
当我们的表中存在类似于 TEXT 或者是很大的 VARCHAR类型的大字段的时候,如果我们大部分访问这张表的时候都不需要这个字段,我们就该义无反顾的将其拆分到另外的独立表中,以减少常用数据所占用的存储空间。这样做的一个明显好处就是每个数据块中可以存储的数据条数可以大大增加,既减少物理 IO 次数,也能大大提高内存中的缓存命中率。