关于分表

分享了一篇关于分表实践的文章 「一次分表踩坑实践的探讨」
临时方案
由于需求紧、人手缺的情况下，整个处理的过程分为几个阶段
第一阶段应该是去年底，当时运维反应 MySQL 所在的主机内存占用很高，整体负载也居高不下，导致整个 MySQL 的吞吐量明显降低（写入、查询数据都明显减慢）。
为此我们找出了数据量最大的几张表，发现大部分数据量在7/8000W 左右，少数的已经突破一亿。
通过业务层面进行分析发现，这些数据多数都是用户产生的一些日志型数据，而且这些数据在业务上并不是强相关的，甚至两三个月前的数据其实已经不需要实时查询了。
因为接近年底，尽可能的不想去动应用，考虑是否可以在运维层面缓解压力；主要的目的就是把单表的数据量降低
原本是想把两个月之前的数据直接迁移出来放到备份表中，但在准备实施的过程中发现一个大坑。
表中没有一个可以排序的索引，导致我们无法快速的筛选出一部分数据！这真是一个深坑，为后面的一些优化埋了个地雷；即便是加索引也需要花几个小时（具体多久没敢在生产测试）。
如果我们强行按照时间进行筛选，可能查询出 4000W 的数据就得花上好几个小时；这显然是行不通的。
于是我们便想到了一个大胆的想法：这部分数据是否可以直接不要了？
这可能是最有效及最快的方式了，和产品沟通后得知这部分数据真的只是日志型的数据，即便是报表出不来今后补上也是可以的。
于是我们就简单粗暴的做了以下事情：
• 修改原有表的表名，比如加上( _190416bak)
• 再新建一张和原有表名称相同的表。
这样新的数据就写到了新表，同时业务上也是使用的这个数据量较小的新表。
虽说过程不太优雅，但至少是解决了问题同时也给我们做技术改造预留了时间。