表里存放的都是原始数据，那么根据不同参数的复杂的聚合统计数据的图表应该怎么做？

性能没达到瓶颈之前，不要想着效率会很低。除非你的sql真的很慢了，而且sql真的很慢了，也不要第一时间考虑去加缓存，应该是优化sql。

我知道用 sql + 编程语言服务端处理，都能做到，但是效率很低、对数据库压力很大，接口响应很慢，不是吗？
反对，效率低，压力大，接口慢没有数据表示出来。程序员都是看数据，一般后台qps又不大，你又没做基准测试，就一口咬定不行。你去做，真的慢了，就去做学习一下sql的优化。

当你达到了sql瓶颈，你再来问这个问题才有意义。杀鸡焉用牛刀

你们说，这种需求，图表怎么搞？比如 api 一次性要返回一个月的数据（横坐标有 30 天）。

一个月的数据，这种数据不会变嘛，历史数据。那就明显是读多于写，那么可以考虑使用MyISAM引擎，而且要让该引擎的表是静态表格式，就会达到一个读很流程快速的状态。

或者你说，不行，现在表已经是InnoDB了，还有数据在写入表。那么，做读写分离是不是能搞定。我们让写表写入数据更快，读表读取数据更快，是不是又优化了一步。

在这里我也是班门弄斧，因为我压根对你的系统一无所知。但是你可以主动去获取知识，比如《高性能Mysql》。

试试这个AnalyticDB

我建议新建一个表。 门店 id，日期 ,订单数量，订单金额

分析用户的真正需求，会为你带来想象不到惊喜。所以一定要重视需求分析！

:relaxed:首先，你说这些业务都是你自己想的，而不是和客户那分析出来的。

:grin:其次，对于需求变更，重新写代码或者更新代码来实现需求很正常，在设计系统时需要考虑可扩展性，而做不到一次编程，业务随意变。

:grinning:现在我认为上面的问题都是真实的需求，让我们一起来想想解决方案。

• 虽然我是做技术的，但是我一般都会先在业务角度来解决，比如上面提到的三个需求，最小单位是天，时间范围不确定。但每天的数据都是多条的，是否可以在每天固定的时间，比如打样时间、固定晚上12点开始对当天的数据进行统计、整合呢？直接放到一个中间表中。
• 和客户详细沟通需求，了解下时间范围的需求点，分析用户真实需求，比如用户常用的是不是按周、月、季度来看呢？如果是这样那么就可以提前对数据进行统计了，这样至少可以满足80%的查询就可以了。
• 慢的原因是因为数据量非常大，既然你这么看重速度，那么数据量应该是非常大的，那么在技术上如何在保证数据正确的前提下，减少数据量是否可行呢，比如之前每天 500 笔销售单，我们可以每天合计，变成一笔合计。

“目前尝试了中间缓存表，就是把图表要展示的数据定义成表，按最小时间单位，使用计划任务，主动计算存表。然后图表的 api 中仅读取中间缓存表来得到数据，而不去访问原始数据。

如果能分析好用户的需求，通过这种方式完全可以解决你担心的问题了。我们在做财务系统的时候，或者现在成熟的财务系统，比如用友，他用采用的复式记账法，一个报表的统计维度很大，而且关联的数据项特别多。那它每晚都会运行很多计划任务，就是在做这样的工作。但即使这样，在查询个别报表时，依然会非常慢，但至少 80% 以上的查询还是比较快的，你看下它的表结构，很多中间表。

Mark一下，看看有没有其他方案~~

mark一下