应用情景：一个日志表，有20列，平均每小时大概能产生30w+的数据，持续插入。由于硬盘有限，需要控制记录数，每小时删除一次60天前的数据这样。一个产品有多个表需要做这个操作，上面说的，是记录数最多的表的情况。一般来说，这种设备配备的最好的硬盘大概就是一个1T-2T的企业硬盘，加索引删除的效果很烂，要删很久，而且大表查询速度很苦逼……拍脑袋想出来的办法是，每天（或每周）生成一个表，到时候从不同分表中删除数据（其实也可以每天0点时直接drop掉表，因为一般人不会关注是不是正好删除了24*60小时之前的日志）。但这样带来两个问题：
1、查询变得比较复杂，起码需要有一个记录表，记录每个分日志表的开始记录与终止记录的时间，要查一个数据的话，就按照这个时间，定向到某一表进行查询（相对还好）。
2、插入变得非常复杂，因为系统时间是可以改变的，要插入的日志也不是实时插入的，日志的生成时间可能和实际插入时间差距半小时以内。所以，如果每次都插入新生成的表，势必会不能保证时间范围绝对统一，否则，只能在每次插入的时候，都检查一下当前记录的生成时间是在哪个表的时间范围内的，插入效率势必悲剧到死。
3、管理变得非常复杂，这样的策略，60天就是60个表。而且，也害怕会不会因为策略复杂，造成别的问题，诸如会不会在创建表，或者改表名的时候，出现超过了数据库建表最大值；或是如果表过多，影响mysql性能等（经验不足，心理恐惧）。
4、错误排查比较麻烦，如果数据库崩溃了（由于产品部署环境经常出现供电不稳断电的情况），那确定发生问题的表位置就变得非常复杂。
求高人给一个好些的解决办法（mysql的分区能不能帮我搞定这个问题呢？）
1、查询变得比较复杂，起码需要有一个记录表，记录每个分日志表的开始记录与终止记录的时间，要查一个数据的话，就按照这个时间，定向到某一表进行查询（相对还好）。
2、插入变得非常复杂，因为系统时间是可以改变的，要插入的日志也不是实时插入的，日志的生成时间可能和实际插入时间差距半小时以内。所以，如果每次都插入新生成的表，势必会不能保证时间范围绝对统一，否则，只能在每次插入的时候，都检查一下当前记录的生成时间是在哪个表的时间范围内的，插入效率势必悲剧到死。
3、管理变得非常复杂，这样的策略，60天就是60个表。而且，也害怕会不会因为策略复杂，造成别的问题，诸如会不会在创建表，或者改表名的时候，出现超过了数据库建表最大值；或是如果表过多，影响mysql性能等（经验不足，心理恐惧）。
4、错误排查比较麻烦，如果数据库崩溃了（由于产品部署环境经常出现供电不稳断电的情况），那确定发生问题的表位置就变得非常复杂。
求高人给一个好些的解决办法（mysql的分区能不能帮我搞定这个问题呢？）
解决方案 »
免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货