如何为大型历史数据构建mysql表？ [关闭]

Posted 2023-02-24

【中文标题】如何为大型历史数据构建mysql表？ [关闭]

【英文标题】：How to structure mysql tables for large historical data? [closed]

【发布时间】：2021-12-27 18:25:49

【问题描述】：

我目前正在做一个 php 网站项目，其中包含 10,000 个客户的月度数据。

客户必须登录才能查看他/她的个人历史每月购买和销售数据。系统管理员必须在每个月底更新每个客户的每月采购和销售情况。

登录后，客户可以查看过去 120 个月的历史月度采购和销售数据。每个客户的历史数据都存储在mysql数据库中。以下是我的问题：

(1) 谁能帮助我如何构建我的数据库表，以便每个客户在登录后都可以查看他/她的历史数据？

(2) 处理10000个客户，有多年历史月度数据，会不会有表格行列数限制？

【问题讨论】：

dev.mysql.com/doc/refman/8.0/en/…

10,000 是相对少数的客户。即使在他们所有人都购买了 1000 件商品的不太可能的情况下，销售历史记录表中仍然只有 10,000,000 行，虽然开始变大，但考虑到适当的索引等，应该仍然不是特别成问题。提防过早优化.

sales 的单独表格会很好。包含客户 ID 和日期的列。客户 ID 将是存储在用户表中的用户 ID。

无论如何这个问题需要更加集中。你到底卡在哪里了？您是否尝试过进行设计并遇到问题？

亲爱的@ADyson 我知道如何编写登录脚本。我遇到的问题是如何构建表格。我想有一张桌子用于销售，另一张用于购买。表列包括 customer_id、date 和 sales_value（对于 sales 表）和 purchase_value（对于 purchase 表）。我担心总行数将达到数百万，我不确定它是否会超过 mysql 行限制。

【参考方案1】：

您远未达到极限。 “数百万”行——即中等大小。 “十亿”是它变得令人兴奋的时候。另一方面，性能可能是个问题。

您会删除“旧”数据吗？如果是这样，我们需要谈谈分区。

最好让主表的PRIMARY KEY以customer_id, date 开头。这将解决许多性能问题。

至于要拥有哪些表，想想您拥有哪些“实体”：customer 和 transaction，但仅此而已。 （我不明白为什么“销售”和“购买”不同。）当您开发查询时，您会发现其他问题，例如用于处理具有多个电话（固定电话、手机、传真、家庭、工作等）。

“在每个月的月底”——为什么不存储每笔交易的发生时间？

【讨论】：

这个答案似乎有比答案更多的问题。从修辞上讲，这个问题应该得到回答吗？

@mickmackusa - 我发现用户的问题通常是“我把自己逼到了这个特定的角落，我该如何解决我造成的混乱？”有时答案是以不同的方式处理任务。我过多的问题可能会让他们放弃他们的计划，或者这可能有助于将问题集中在他们[尚未]想到的某个方向上。