一个大型MySQL表与20-50个较小的表？

我正在启动一个项目，其中查询结果的性能（速度）非常重要

情况：

• 大约20-50种产品（将随时间增加：约3种/年）
• 每个产品都有一个配置文件页，其中包含大约20个需要存储的变量
• 每种产品都有一个将更改的定价（插入/添加）——每日--
• 每个产品还将有每月、3个月、6个月、1年、3年价格的VAR，并随机更新

• 输出1（估计每天5000次）

所有产品、当日定价、差价、差价百分比、前价格

• 输出2（按范围搜索个人产品|视图未知，估计每天100个视图）

日期、价格、差价、差价百分比、以前的价格

• 上瘾。将需要随机卖出定价

注：此项目基于ExpressionEngine构建

我的主要问题是，我是否应该制作一个表，用产品ID保存所有产品信息，然后将所有产品的每日定价都放在一个表中。然后，第二个表中所有产品的所有月度定价等，因为每种类型的定价一次只能使用一种类型。

或。我是否应该制作20-30张表来存储他们自己的每日价格？然后在查询时使用JOIN

---

我已经研究了很多类似的问题和答案，但我似乎找不到足够接近的情况

我将始终倾向于单表方法，而不是一组表

您应该在表上使用索引，这将大大提高性能

维护自己的滚动表分区的开销远远大于单表方法

每个“实体”应该有一个表

---

因此，产品静态数据表、定价数据表等采用父子方法。并确定表的正确关系。此外，数据的处理将取决于后端使用的软件。

输出1。任何时候，执行完整表扫描以返回数据库中的所有行都可能会非常耗时。然而，20-50个产品是愚蠢的改变，数据库应该没有问题。如果你开始添加很多产品，你总是可以引入分页，每页显示100个左右的产品。第二种方法是将主页缓存一段时间并定期刷新

产出2。只要您有产品ID或标题索引，单个产品的查找就会非常快速

---

20-30个表的维护听起来像是地狱，那么多的连接将是一场噩梦。不要试图过早地优化。只有在发现问题时才关注它。

首先，你的问题并不完全清楚——你是在问是否应该对数据进行反规范化，还是应该对数据进行分区

第二，这两个问题的答案都是“不”。或者，更准确地说，“不，求你了，求你了，不，以一切神圣的名义——不！”

你的数据库将会很小——每年有365次价格变化的50种产品仍然只有15K条记录。您甚至还没有接近设计得体的“传统”数据库模式会很慢的地步；非规范化和分区都会产生大量的维护开销，使应用程序更加脆弱，并且需要大量的开发时间

---

我强烈建议构建一个规范化的数据模型，用大量数据（至少是预期最大值的两倍）填充它，运行预期运行的查询，然后通过测量查询的性能来确定是否存在问题。如果这样做，请优化查询。如果速度仍然缓慢，请购买更大/更好的硬件。如果它仍然是慢的，考虑去正规化。如果这太慢了，你是在为Facebook工作

回答你的问题是不可能的。对于如此含糊的解释，两个答案都不正确。但问题是——只要你问这样的问题，那么有可能你现在不太应该关心使用多少张桌子。非常感谢。这真的有助于缓解我决定走哪条路的压力。我对ExpressionEngine没有任何经验，但我使用mysql处理每天40万行的数据库，只有非常复杂的查询速度慢。如果我只返回几百行或几千行，它的速度很快。