结合我前面的建议扩容tiflash后，使用tiflash的方案，双管齐下
tidb目的就是为了实现hatp，当然这是以后数据库趋势。所以你没有必要大宽表。直接先试试在tiflash上的效果。
毕竟假设你一次性insert select过去了。后面再发生的insert和update怎么过去？
题主这种搞法，应该是mysql里面常用的手段，设置字段冗余来减轻数据库的计算压力。分布式里面就是为了解决那种痛点啊
我们的应用场景非常……变态。
本质上是对用户的日志行为进行分析，但是产品设置了大量可以自定义的过滤器。
比如用户不但可以选择统计多少天的数据(最近一周、最近一个月、最近三个月、最近半年、…)，还能定义对于每一天来说，统计几点到几点的数据(也就是说，用户可以自由选择统计最近三个月内，早上7点45到下午3点20的日志数据，后者可以随意变更且精确到分钟)。
除了时间之外，用户还可以给日志行为添加多个标签，可以多选，一个行为可以横跨多个标签，且如果选中了多个标签，还要对行为进行去重。
然后用户的历史行为可以被编辑、用户下面某些行为还要支持可见性调整，一会可见一会不可见。
在我看来这就是愚蠢的产品搞出了一个完全没有办法做离线计算、只能进行实时OLAP处理且变更频繁的需求。
头疼……
所以我们初步的想法是弄一个大宽表出来，然后用TIKV来应对可能会出现的对历史数据的频繁更新，用TIFLASH来应对实时的OLAP。
这种场景，其实只要不是精确到一天之内，都还是可以做离线计算的，这个一天之内的时间段，，，反正产品只管提需求，提个造航母吧，哈哈
那就的做二级统计了，直接统计历史数据肯定扛不住啊。