我在十字路口，我不知道该选择什么，请告诉我。
有一个数据库，其中包含商品表及其在单独表中的一些属性，或者更确切地说：
good (~2k Записей)
catalog (~50 записей)
form (4 записи)
type (~100 записей)
color (10 записей)
sostav (5 записей)
sizes (~200)
width (~50)
相应地，在这 11 个（包括链接<->表）表中的每一个表中都有第 N 个列数。所有表总共约有 150 个。
问题是如何最好地做到这一点：
- 6 个不同的查询，只有必要的 JOIN 和列（1 个用于选择产品，5 个用于显示过滤器）+ JOIN 和条件（如果选择了过滤器和/或排序）
- 来自包含所有 JOIN 和所有列的查询的存储过程，并在 PHP 中进一步处理所有这些混乱（在我看来，这根本不是最优的，但你永远不会知道）
- 1 查询临时表并从中进一步选择（仍然很长，因为完整查询本身需要 2 到 20 秒）+ 如果我没记错的话，将为每个打开的连接分别创建临时表。因此，20 个并发用户 - 20 个约 300k 行的临时表
- 创建一个表，其中包含所有 JOIN 的选择结果，并为传入表的所有 PK 和所需列上的索引创建一个复合 PK，并定期更新它。假设每小时/5 小时/天一次。
- 选项 4，但通过触发器更新数据（我还不知道它是否可能在触发器中），产品数据不经常更新，但一次更新很多并且每次都触发触发器...添加 1 个产品将其与 5 个相关联尺寸 - 6 个调用触发，至少... + 类型 + 颜色...（经理每天可以更改/添加 10-50 种产品）
- 什么是正常选项？
在任何情况下，所有查询中应该包含的最小 JOIN 集是：
goods - собственно, товары
catalogs - категории товаров (для проверки вкл/выкл)
size_type_1 - размеры (для проверки остатков)
另外，在每个请求中都会有一个计算в наличии/ нет в наличии+ HAVING 根据这个计算过滤器（应该只有实际数据）
这是摆在我面前的挑战。正如我可以描述的那样，这似乎是所有细节。我真的希望得到你的帮助:)
谢谢大家。
我选择了一些中间选项：一个缓存表，其中包含通过所有表的完整 JOIN 选择获得的所有连接表的 ID。
在此表中最常用的字段上创建了冗余链接和组合索引。该指数被证明是“过度的”。对于 ~ 10mb 的表，索引结果是 ~ 36mb。但是需要这样的索引。比较 InnoDB + 索引选项和没有索引的 MEMORY。即使在内存中，所有查询的时间都超过 3 秒，而在具有索引的表中则为 < 0.5 秒。
几乎任何复杂度的平均查询执行速度只有必要的 JOIN，因此，结果是 ~ 0.003 秒（完全选择，但是，对于任何无条件的 JOIN，执行 ~ 0.7 秒，但不会被使用)，反对 2-20 秒，在起始帖子中使用不同的选项。
唯一不利的是该表必须“处理”或根据时间表更新。我选择了“handles”选项，即只有更新了商品余额后才会更新缓存表。因为 即使经理添加了产品，在余额更新之前，用户也不会找到该产品。
最终的模型是这样出来的，有兴趣的可以看看：