刚接手系统的时候，发现过亿的操作日志写在 MySql的一张表中，主要是记录用户登录，做了那些动作（增删改查），随之便做了如下处理（索引、sql均已优化过了）：

1、刚开始接手以为查询并不频繁，做了分区，后来发现查询很频繁；

2、对数据做了分表，一个月一个表，发现夸月查询又很频繁，并且每个用户都强烈要求看至今所有的数据；

3、这些查询会集中在某个点并发查询，会产生大量的慢查询导致影响到其他业务，所以对这些查询频繁的用户做了redis数据缓存；

以上做完之后，系统算是稳定下来了，但随着用户的增加单表数据也会随之增加，并且在某个点同样会爆发高并发访问数据库的情况，近期在考虑是否可以用搜索引擎来做这个事情，因为历史数据是不可变的，思路如下，请大神指点：

1、将此模块单独出一个微服务

2、创建总索引

3、每天定时增量索引，并将增量索引数据搬入和业务隔离的日志数据库中对应历史表（同样每个月创建一个表）

4、在查询的时候有多种情况的考虑，对当天的数据进行数据库查询，对历史数据进行搜索引擎索引查询，若夸有当天和历史数据的查询，进行分别查询后结果合并

不知此方法是否可行，因为我在网上找了很久，都并没搜索到使用搜索引擎这种方法，全都是分库分表，或者用hbase等解决方案，所以担心是否会有弊端。

关于频繁操作数据表的优化问题