非规范化后的成本（％CPU）大致相同？答案

【问题标题】：Cost (%CPU) around the same after denormalization?非规范化后的成本（％CPU）大致相同？
【发布时间】：2021-10-01 17:49:13
【问题描述】：

使用 SQL 甲骨文。我创建了一个查询来查找食品订单的总数。

EXPLAIN PLAN FOR
SELECT FOOD.F_NAME, COUNT(ORDERS.O_ORDERID)
FROM ORDERS
INNER JOIN CUSTOMER ON O_CUSTID = C_CUSTID
INNER JOIN FOOD ON C_FOODKEY = F_FOODKEY
GROUP BY FOOD.F_NAME;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

这将返回计划表输出中第 0 行的 3250 的成本 (%CPU)。

我了解到非规范化会加快查询速度并降低成本。在这种情况下，我将表中的食物名称从FOOD 复制到ORDERS 以避免INNER JOIN。我应该获得更好的成本 (%CPU) 使用率。

我接下来使用了这个查询

EXPLAIN PLAN FOR
SELECT ORDERS.F_NAME, COUNT(ORDERS.O_ORDERID)
FROM ORDERS
GROUP BY ORDERS.F_NAME;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

成本 (%CPU) 没有太大变化 - 计划表输出中第 0 行的值为 3120。

INNER JOIN 的非规范化和删除不应该提高我的成本吗？在我的情况下，改进是如此微不足道。这里有什么问题？

【问题讨论】：

第二个查询看起来不太正确。如果FOOD 表不是查询的一部分，如何选择FOOD.F_NAME？
我的错！编辑错误。我已将其更正到正确的表格中。
请发布您的计划。它可能取决于许多参数。

标签： sql oracle denormalization denormalized

【解决方案1】：

评论太长了。您将不得不研究执行计划。但是，主键上的连接通常不是特别昂贵。

昂贵的是GROUP BY，因为这需要移动数据。您可以尝试在第二个查询中在F_NAME 上添加索引。

您的数据模型也很不寻常。不清楚为什么名为FOOD 的列会存储在CUSTOMER 级别。

【讨论】：

【解决方案2】：

C_FOODKEY 应该很可能是 O_FOODKEY 才有意义

您不需要非规范化。您正在做的是-您通过连接分解所有行，然后将它们组合在一起。不要一开始就这样做，尝试这样的事情

SELECT FOOD.F_NAME, 
      (SELECT COUNT(*) 
       FROM ORDERS 
       WHERE O_FOODKEY = F_FOODKEY) AS fCount
FROM FOOD

【讨论】：