触发了慢日志告警应该怎么办

这么个场景：

       业务场景：要统计所有门店不同类型的商品的半年销量，可能用于用户侧的展示或者商户侧的展示

前提：1、两个表：一个订单表、一个订单商品表（假设主子表之间1:8的比例、时间跨度1年）；  2、闲时统计；3、所有查询条件都能走索引（这种时间范围内的索引基本会失效的）；

        一般做法（不用思考的大部分人采用的做法）：一条sql统计半年的所有门店的所有商品的销量；

这种做法有问题吗？一般情况没有问题；主要看数据量，放在两千万内的数据量（假设2万订单）都没问题（有可能会触发慢日志告警、慢点也没有关系 毕竟闲时执行也不影响正常的业务嘛）；

再加大数据量，到达将近1亿这个数量（主表扩大到5倍），估计GG了吧；

        

        思考一下问题：

        1、这种统计类型的业务数据是否需要绝对的准确，是否需要剔除退款的数据；（业务需求）

        2、能否增量统计，比如按天统计，将每天统计的数据累加起来，这样每次统计时只需要统计1天的数据量；

        3、假如要求剔除掉退款的绝对精确的数据、且已目前的人员的时间、精力和技术暂时不能做到增量统计，这种情况如何处理？难道就一个sql搞到死吗？

        解决方案：

        1、如果能容忍统计数据中包含退款数据（不要求绝对精确），增量统计，就一条sql，然后主日统计累加；

        2、如果要求绝对精确，不能增量（做不到增量统计），还是那个sql，分批次统计处理，一次执行半个月或者1个月的数据，一共执行6次或者12次；

        3、相对于总数据量或者入参时间，一次查询尽量缩小范围，查询尽量少的数据，可以分批次查询；