MySQL优化——表设计

问题

    伴随着项目上线，随着数据量的增长，影响系统性能方面也被充分暴露，小编借这次机会重新温故一下表设计，目的通过良好的表结构来优化系统的性能。

    小编这次参与的项目一共涉及七个服务，而小编刚好隶属于其中的后两个服务中，所以调用其他服务的数据比较多，再加上这个两个服务的数据比较多，所以数据对小编造成的影响非常的严重。例如小编在存储学生成绩的时候涉及到上课班，行政班，学生个人基础信息等内容，为了存储学生成绩表的信息基本上之前的六个服务均有调用，这样不仅仅是服务之间的耦合性比较强，而且操作效率相对来说很低，而且在系统使用高峰期的时候占用cpu过高，造成严重影响。

影响因素

出现这种问题，反思了自己实现过程，主要是以下几个方面

1、业务逻辑可以不可以在优化；

2、目前涉及到的sql语句能不能在优化；

3、表结构是否可以继续完善；

小编今天主要说第三方面，从表设计的三范式来思考

三范式

第一范式：属性保持原子性，不可再分（这一部分基本上都可以做到）

第二范式：非主键字段必须依赖与主键（第二范式着重描述一个表只能描述一件事情）

第三范式：消除传递依赖，在非主键之间没有必然的依赖关系

依赖传递：其中第三范式涉及到一个概念，传递依赖，非主键中一个字段可以推导出另一个字段，那么这两者关系称之为传递依赖。

以前学习这一部分的总感觉这三个范式搞在一起乱哄哄的，最近才明白原来这个三范式是依次递减的关系。先看下面的图

范式一，所有键；范式二，一个表的主键和非主键；范式三：非主键中关系；

学习的时候，一般都要我们尽量遵守三范式的设计规范，因为这样设计的表结构是最规范的，同样是最简洁的，但是实际生产过程这样表结构会造成性能的下降，因为有的时候需要的字段需要联查多张表，再加上数据量的增长，会造成系统性能的极速下降。

因为这样的问题会造成数据库设计的规范性和性能产生矛盾，如何解决这样的矛盾？

    没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。

如何冗余？

    在表的1对N情况下，为了提高效率，可能会在1这个表设计字段，以便提速！

【总结】

    设计良好的表结构只是MySQL优化的万里长征的第一步啊，道路漫长，且行且珍惜！