最近一直在想一个问题
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 出来的，并没有实践过，有没有哪个小伙伴 如果看了 觉得可行的，就去试试吧？然后把结果告诉我，哈哈哈