Question

我正在执行此查询

SELECT sum(c.cantitate) AS num, 
produse.*,
cc.seo
FROM produse
LEFT JOIN comenzi c ON produse.id = c.produs
LEFT JOIN cosuri cs ON c.cos = cs.id
LEFT JOIN categorii cc ON produse.categorie = cc.id
WHERE cs.status = 'closed' AND produse.vizibil ='1'
GROUP BY produse.id
ORDER BY num DESC
LIMIT 14

受影响的行：0找到的行：14警告：0 1个查询的持续时间：11.734秒没有GROUP BY和总和它需要16ms 此查询用于基于数量销售的顶级销售14产品列表如何重写查询以获得更好的性能？

Answer 1

也许你需要在加入之前生成总和...

每条评论都要注意原始问题：

你是否想要在加入之前的comenzi之和cosuri和categorii可能有多个记录导致可能膨胀的金额或在加入之后可能是一个虚增的金额？

SELECT c.cantitate AS num, 
produse.*,
cc.seo
FROM produse
LEFT JOIN (Select produs, cos, sum(cantitate) as cantitate 
           FROM comenzi 
           GROUP BY produs, cos) c ON produse.id = c.produs
LEFT JOIN cosuri cs ON c.cos = cs.id
LEFT JOIN categorii cc ON produse.categorie = cc.id
WHERE cs.status = 'closed' AND produse.vizibil ='1'
ORDER BY num DESC
LIMIT 14

实施例：如果comenzi的记录ID为1，cos为'A'且3为3 并加入基于CS.ID的cosuri，ID为'A'列出3次，然后计算3 + 3 + 3（9）而不是Just 3 ...这可能是问题。如果我们提前计算总和，我们就避免了这个问题（如果它是一个），并且根据cosuri和categorii之间的基数来计算这些值的开销可能是数千次。哪个...可以提高性能。

要确定这是否会提高性能，我们实际需要

了解结果的要求（加入之前或之后的总和？）
查看一些示例数据以及每个表的统计信息以了解记录计数
了解表连接和任何where子句之间的索引标准
关于数据库的解释计划的视图。

如果没有这些细节，我们无法确切知道什么是真正有用的。没有事实，一切都是猜测;这里很少有人）

GROUP BY和sum（）性能问题

1 个答案: