有张表的数据每天变动能达到千万条数据，这样时间一长，查询和存储都是非常慢，有什么解决方案？
目前，我们能想到的是普通分区，Hash分区？这两个选择哪一种比较好，还有没有其他的解决方案呢？
如果分区后，开发可能要对查询逻辑要做调整，改动变化大吗？
如果不做分区，比如1个月的历史数据作为冷数据存储，能按照日期分离出来吗？
不见得会慢，只要是单点读写那照样快。
每天千万变动不算多，如果是集中写入那会有热点问题，但是为此而采用hash分区会导致数据清理困难。
使用日期范围分区可以很方便的清理过期数据。
至于以后能否把历史数据分离出来，这个用不用分区都一样的难度。
频繁的变动是指插入还是修改删除？
主要业务事务数据维度发生当天查询更新比较频繁，除了当日的数据拆出来，但是历史数据是不能删，分析查询报表的维度是一年之内。
所以，有没有有一种好的策略，自动按照日期拆分分区业务存储使用，又不影响分析部门查询分析数据的解决方案？
replace 更新插入，直白点就是设备心跳数据，还有就是操作日志，比如开关等等
我们也有这种业务场景，但是好像几十ms延时还能接受，update批量更新，分析用的场景同步到了另外一个tidb集群专门做分析用。
目前这张表每天的存储大概6g,如果不及时拆开，冷备份或者隔离历史数据的话，一则是优化性能，业务没必要查询那么大的表，二则，数据太多不做定期的删除备份，那后期备份或者迁移 会比较难
分区 能解决我的问题吗？
是要定期归档。
你要说什么后期迁移数据什么的，那分表比分区都好，只是代码写起来比较麻烦。
性能真没必要优先考虑，分区表的优势是清理数据，tidb的分布式设计决定了分区表的性能相比普通大表并比一定有什么提升，本身就是分布式的，相当于sharding给你做好了。
说白了，你担心未来归档和备份，那分表最好，分不分区都解决不了这个问题。
你担心性能，那分不分表还是都差不多，分区只解决写入热点或数据清理，记住这点即可。
如果是我，我肯定日期范围分区走起了。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。