对MySQL数据量日益增长产生的一点小想法

最近一直在想一个问题

  MySQL数据量日益庞大,目前单表总记录数有 300W+,导致sql语句执行的速度变慢,如果一直这样增长下去,总有一天会爆炸的。怎么办??怎么办??

 

第一:想到的必然是 添加索引,可是索引偏偏是把双刃剑,提升了查询的速度,却活生生的影响了插入的效率

     所以索引的话,也只是能做到在一定数据量下,达到查询与插入的最优化,但是遇到持续增长的数据量,也是力不从心。

 

第二:想到的是 主从复制,想想好像很难弄的样子,会不会出问题?我这么懒,才不想去搞这个。。

 

第三(YY):首先,我们要思考一下,这些日渐庞大的数据表,它里面的数据都是经常用吗?

   还是说有大部分数据都处于一种很尴尬的处境:(保存着占空间,删除了又怕需要它),通俗点说就是“占着茅坑不拉屎”。。

   如果说是属于第二种情况,那么我们是不是可以尝试这么做:

    每条记录在插入的时候,都带一个“数据年龄”字段,初始值 = 插入时间 了,之后的话,记录被调用(查询,更新)时,它的“数据年龄” = 当前时间,这样那些长时间不被使用的数据就变成 陈年老数据 了,同时在MySQL开启一个定时器,每24小时执行一次,将“数据年龄”超过6个月的数据删除,并将这些删除的数据插入到与原表对应的一个“历史表”中,比如 “订单表” 对应 一个 “订单历史表” 。

    这样一来,“订单表”的数据就都是 数据年龄 小于 6月的数据了,从而阻止了 一个表的数据持续增长的状态

伴随的几个问题以及相应的解决想法:

  1:要如何查询总记录数?

    a) 分别查询 正常表 和 历史表 的总记录数,然后加起来

    b) 在当前数据库 创建一个专门用来记录此数据库中的每个表信息(包括表名称,总记录数等)的 "information表", 类似于 MySQL 的 information_schema数据库中的TABLES表。这种方式想想维护起来还是比较麻烦

    c) 暂时就想到两种

  2:如果我要调用的历史表中的数据怎么办?

    a) 当在 正常表中查询返回没有结果时,就转去 历史表中搜索,如果找到了,那么允许在历史表中执行本次操作,在这之后将 此条记录 重新写入到 正常表中,更新它的 “数据年龄”,并且将它从历史表中删除

    b) 看a

  3:涉及到分页查询所有记录,并按某个条件排序的咋搞?

    a) 比如 按金额倒序 查询前20条:分别 给两个表 按金额倒序 查询前20条,将 两个结果集合 整合 并取其中符合条件的20条。

    b) 想不出来了

  4:暂时没有想到其他问题

 

 总结:以上都是 我 yy 出来的,并没有实践过,有没有哪个小伙伴 如果看了 觉得可行的,就去试试吧?然后把结果告诉我,哈哈哈

posted @ 2016-09-28 15:12  EEEEET  阅读(610)  评论(0编辑  收藏  举报