MySQL数据库优化总结
来源:未知 责任编辑:责任编辑 发表时间:2014-02-02 17:50 点击:次
对于一个以数据为中心的应用,数据库的好坏直接影响到程序的性能,因此数据库性能至关重要。一般来说,要保证数据库的效率,要做好以下四个方面的工作:数据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统,这个顺序也表现了这四个工作对性能影响的大小。下面我们逐个阐明:
一、数据库设计
适度的反范式,注意是适度的
我们都知道三范式,基于三范式建立的模型是最有效保存数 据的方式,也是最容易扩展的模式。我们在开发应用程序时,设计的数据库要最大程度的遵守三范式,特别是对于OLTP型的系统,三范式是必须遵守的规则。当 然,三范式最大的问题在于查询时通常需要join很多表,导致查询效率很低。所以有时候基于性能考虑,我们需要有意的违反三范式,适度的做冗余,以达到提 高查询效率的目的。注意这里的反范式是适度的,必须为这种做法提供充分的理由。下面就是一个糟糕的实例:
在这里,为了提高学生活动记录的检索效率,把单位名称冗余到学生活动记录表里。单位信息有500条记录,而学生活动记录在一年内大概有200万数据量。 如果学生活动记录表不冗余这个单位名称字段,只包含三个int字段和一个timestamp字段,只占用了16字节,是一个很小的表。而冗余了一个varchar(32)的字段后则是原来的3倍,检索起来相应也多了这么多的I/O。而且记录数相差悬殊,500 VS 2000000 ,导致更新一个单位名称还要更新4000条冗余记录。由此可见,这个冗余根本就是适得其反。
下面这个冗余就很好
可以看到,[学生考试总分]是冗余的,这个分数完全可以通过[得分情况]汇总得到。在【学生考试总分】里,一次考试一个学生只有一条记录,而在【得分情 况】里,一个学生针对试卷里一个小题的一个小问一条记录,粗略的算一下比例大概是1:100。而且判卷子得分是不会轻易变的,更新的频率不高,所以说这个 冗余是比较好的。
一、数据库设计
适度的反范式,注意是适度的
我们都知道三范式,基于三范式建立的模型是最有效保存数 据的方式,也是最容易扩展的模式。我们在开发应用程序时,设计的数据库要最大程度的遵守三范式,特别是对于OLTP型的系统,三范式是必须遵守的规则。当 然,三范式最大的问题在于查询时通常需要join很多表,导致查询效率很低。所以有时候基于性能考虑,我们需要有意的违反三范式,适度的做冗余,以达到提 高查询效率的目的。注意这里的反范式是适度的,必须为这种做法提供充分的理由。下面就是一个糟糕的实例:
在这里,为了提高学生活动记录的检索效率,把单位名称冗余到学生活动记录表里。单位信息有500条记录,而学生活动记录在一年内大概有200万数据量。 如果学生活动记录表不冗余这个单位名称字段,只包含三个int字段和一个timestamp字段,只占用了16字节,是一个很小的表。而冗余了一个varchar(32)的字段后则是原来的3倍,检索起来相应也多了这么多的I/O。而且记录数相差悬殊,500 VS 2000000 ,导致更新一个单位名称还要更新4000条冗余记录。由此可见,这个冗余根本就是适得其反。
下面这个冗余就很好
可以看到,[学生考试总分]是冗余的,这个分数完全可以通过[得分情况]汇总得到。在【学生考试总分】里,一次考试一个学生只有一条记录,而在【得分情 况】里,一个学生针对试卷里一个小题的一个小问一条记录,粗略的算一下比例大概是1:100。而且判卷子得分是不会轻易变的,更新的频率不高,所以说这个 冗余是比较好的。
相关新闻>>
最新推荐更多>>>
- 发表评论
-
- 最新评论 更多>>