Database design 面向销售报表的Mysql数据库设计

因此，我决定如何为这份销售报告设计我的数据库

下面是一个场景。我有10万以上的用户，每个用户每天进行0次或更多的销售。如果他/她有0个销售额，则当天不会为该用户存储任何内容，否则如果他/她有多个销售额，则当天的销售额只会增加1

现在的问题是关于数据库设计（关注最终性能）。一种简单的方法是只创建一个带有日期和用户id的表，并使用WHERE子句获取给定用户的每周、每月和年度销售业绩

Table: user_sales_counter
--------------------
user_id, sales, date

然而，我在这里看到的问题是，如果在六个月后，我想查找某个用户的一周报告，那么在最坏的情况下，我必须遍历1800万条记录

因此，我想问的确切问题是，我是否可以再创建三个表用于每周、每月和每年的记录保存，这将允许我做两件事，我可以删除每日销售数据，比如说超过2个月的数据，但我仍然可以访问用户的每周、每月等销售记录，因为这些表的清除可以设置为，例如1岁或以上

Table: weekly_sales_counter
---------------------------
week_no, month_no_year, user_id, sales

Table: monthly_sales_counter
----------------------------
month_no_year, user_id, sales

Table: yearly_sales_counter
---------------------------
year, user_id, sales 

我正在使用Redis进一步减少对这些表的读取

这种方法的缺点是，我必须运行4个查询来记录单个销售计数器，而不是一个查询，因为每个表的计数器必须分别递增

最好的解决方案是什么？一张桌子还是第二张？或者你有没有其他我可以采取的方法

---

感谢

根据我的经验，从交易的百万数据查询将需要越来越长的时间。我的建议是：

创建一个表以保留将来要使用的最小周期单位

创建crontab或trigger或任何东西来统计销售，并根据该表上的用户id进行分组，您可以在一天结束时或一周结束时进行统计，尝试找到最佳方法

每当您想要显示该计数器时，您只需从该表中选择，再次按用户id分组，它将比事务表上的计数要轻

---

单表似乎是解决甲烷问题的正确方法，但可以解释为什么？而且，多表方法会有什么问题？通过创建足够多的不必要的冗余，您正在解决一个问题（这是不存在的）。但是假设它确实存在，那么应该采取什么方法呢？1800万条记录，有适当的索引和数据类型，不应该成为问题。