问题
伴随着项目上线,随着数据量的增长,影响系统性能方面也被充分暴露,小编借这次机会重新温故一下表设计,目的通过良好的表结构来优化系统的性能。
小编这次参与的项目一共涉及七个服务,而小编刚好隶属于其中的后两个服务中,所以调用其他服务的数据比较多,再加上这个两个服务的数据比较多,所以数据对小编造成的影响非常的严重。例如小编在存储学生成绩的时候涉及到上课班,行政班,学生个人基础信息等内容,为了存储学生成绩表的信息基本上之前的六个服务均有调用,这样不仅仅是服务之间的耦合性比较强,而且操作效率相对来说很低,而且在系统使用高峰期的时候占用cpu过高,造成严重影响。
影响因素
出现这种问题,反思了自己实现过程,主要是以下几个方面
1、业务逻辑可以不可以在优化;
2、目前涉及到的sql语句能不能在优化;
3、表结构是否可以继续完善;
小编今天主要说第三方面,从表设计的三范式来思考
三范式
第一范式:属性保持原子性,不可再分(这一部分基本上都可以做到)
第二范式:非主键字段必须依赖与主键(第二范式着重描述一个表只能描述一件事情)
第三范式:消除传递依赖,在非主键之间没有必然的依赖关系
依赖传递:其中第三范式涉及到一个概念,传递依赖,非主键中一个字段可以推导出另一个字段,那么这两者关系称之为传递依赖。
以前学习这一部分的总感觉这三个范式搞在一起乱哄哄的,最近才明白原来这个三范式是依次递减的关系。先看下面的图
范式一,所有键;范式二,一个表的主键和非主键;范式三:非主键中关系;
学习的时候,一般都要我们尽量遵守三范式的设计规范,因为这样设计的表结构是最规范的,同样是最简洁的,但是实际生产过程这样表结构会造成性能的下降,因为有的时候需要的字段需要联查多张表,再加上数据量的增长,会造成系统性能的极速下降。
因为这样的问题会造成数据库设计的规范性和性能产生矛盾,如何解决这样的矛盾?
没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,允许冗余。
如何冗余?
在表的1对N情况下,为了提高效率,可能会在1这个表设计字段,以便提速!
【总结】
设计良好的表结构只是MySQL优化的万里长征的第一步啊,道路漫长,且行且珍惜!