我正在启动一个项目，其中查询的每个结果的性能（速度）非常重要。
情况：
每个产品还将有一个每月、3 个月、6 个月、1 年、3 年价格的 VAR，随机更新
输出 1（估计每天 5,000 次观看）
所有产品，当日定价，价格差异，百分比差异，上一个价格
日期、价格、差价、百分比差、过往价格
注意：本项目基于 ExpressionEngine
我的主要问题是我是否应该制作一张表格，将所有产品信息与产品 ID 一起保存，然后将所有产品的所有每日定价都放在一个表格中。然后是第二张表中所有产品的所有月度定价等，因为每种定价一次只能使用一种类型。
或者。我应该制作 20-30 个表格来存储他们自己的每日定价吗？然后在查询时使用 JOIN
我已经研究了很多类似的问题和答案，但我似乎无法找到足够接近的情况。
输出 1. 任何时候执行全表扫描以返回数据库中的所有行都可能会变得很耗时。但是 20-50 个产品是零钱，数据库应该没有问题。如果您开始添加大量产品，您可以随时引入分页并在每页显示 100 个左右的产品。第二种方法是将主页缓存一段时间并定期刷新。
输出 2。只要您有产品 ID 或标题索引单个产品查找应该非常快。
维护 20 到 30 个表听起来像是地狱，做这么多的连接将是一场噩梦。不要试图过早地优化。只有在发现问题时才关注它。
我将始终倾向于单表方法而不是一组表。
您应该在表上使用索引，这将大大提高性能。
维护自己的滚动表分区的开销远远超过单表方法。
每个“实体”应该有一个表。
所以一个产品静态数据表，一个定价数据表等等。
采用父子方法。并确定表的正确关系。此外，您的数据处理将取决于您将在后端使用的软件。
首先，您要问的内容并不完全清楚-您是在问是否应该对数据进行非规范化，还是应该对数据进行分区？
其次，这两个问题的答案都是“不”。或者，更准确地说，“不，拜托，拜托，不，以所有神圣的名义——不！”。
您的数据库将会很小 - 50 种产品，每年 365 次价格变化仍然只有 15K 条记录。您甚至还没有接近设计得体的“传统”数据库模式会变慢的地步；非规范化和分区都会产生主要的维护开销，使应用程序更加脆弱，并需要大量的开发时间。
我强烈建议建立一个规范化的数据模型，用大量数据填充它（至少是预期最大值的两倍），运行你期望运行的查询，然后通过测量性能来确定你是否有问题查询。如果这样做，请优化查询。如果它仍然很慢，请购买更大/更好的硬件。如果它仍然很慢，请考虑去规范化。如果这太慢了，那你就是在为 Facebook 工作。