ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 数据库优化小计

数据库优化小计

原创 Linux操作系统 作者:bisal 时间:2013-09-12 22:51:35 0 删除 编辑

周一夜间进行了一次XX业务相关的数据库表优化。


原因:

一共4张表,数据量不大,最小的40万记录,最大的300万,大小不超过300MB。但由于历史原因,表没有建立索引,对应的服务使用的SQL千姿百态,修改起来难度有点大,容易改错,涉及的全国客户较多,大部分都是全表扫描,在秒级的响应时间,但大多客户还能忍着。


目标:

对于此类无法通过建立索引提高响应速度的表,采用降低数据量,即水位线的方式,提高全表扫描的效率。


方案:

经过多次改进,行程可用的方案:

第一部分:

1、CREATE TABLE XXX_20130910 AS SELECT * FROM XXX;

利用原表建立一个中间表。

2、TRUNCATE XXX;

Truncate原表。

3、INSERT INTO XXX SELECT * FROM XXX_20130910 WHERE 7天;

将7天的数据插入原表。

此时启动相应服务,这个过程可以保证利用最短的时间恢复生产表的使用。

第二部分:然后建立历史表:

1、CREATE TABLE XXX_HISTORY AS SELECT * FROM XXX_20130910 WHERE 1<>1;

利用中间表建立一个空的历史表。

2、建立夜维,用于每天将生产表7天之前的数据导入历史表。

整体操作完成后,用于生产的表保持7天的数据量,即使业务量增加,水位线也不会上升太多,保持在一定的高度。同时通过将生产表历史数据导入历史表的方式,既保证了历史数据的备份,也保证了生产表的数据量。


上线:

第一部分包括检查的时间总共耗时20分钟。与用户确认测试后开始第二部分,大约用时10分钟。


效果:

当天上线后的效果还可以,大多应用的响应时间从秒级,下降到xx毫秒级,有待一段时间内的查看。


总结:

整体过程经过来多次修改与总结,且为上线当天整理了步骤手册,标明了每步的操作以及注意的地方,所以操作当天比较顺手,主要是与多个客户联系停止应用、测试应用比较耗时,不同的客户配合的程度不同,不过还算是比较配合。

对于数据库表的优化,以上操作其实已经精简到最简单的语句了,我觉得优化操作不在于多么的复杂,最重要的是简单、有效、安全,何况是没有用户驱动的优化,做好了可能不会说你什么,但做错了就有人叫了,得不偿失,因此不同的优化操作,可能选择的方法不同,但核心应该坚持“简单、有效、安全”,这样才能做到画龙点睛的效果。个人见解,欢迎拍砖!

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7192724/viewspace-772658/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle ACE,10g/11g OCP,11g OCM,国内首批Oracle YEP成员(Oracle Young Expert Program,Oracle用户组年轻专家项目),EXIN DevOps Master,Oracle爱好者,微信公众号:bisal的个人杂货铺

注册时间:2013-07-26

  • 博文量
    340
  • 访问量
    2622869