MySQL group by+；以令人费解的速度订货

我不确定到底发生了什么，但我认为MySQL应该能很好地处理这个问题

我有这样的SQL

SELECT u.id AS user_id, SUM(t.amount) AS total
FROM user u
INNER JOIN transaction t ON t.user_id = u.id
WHERE u.condition = true
GROUP BY u.id
ORDER BY total DESC;

此查询运行10秒

如果我删除ORDERBY子句，时间大约是4秒

桌子很大，但分组后我只有40行。对40行进行排序真的需要6秒钟吗？我认为这应该由优化器来处理

但是，如果我像这样运行查询：

SELECT *
FROM (
    SELECT u.id AS user_id, SUM(t.amount) AS total
    FROM user u
    INNER JOIN transaction t ON t.user_id = u.id
    WHERE u.condition = true
    GROUP BY u.id
) data
ORDER BY total DESC;

此查询运行4秒钟。我知道我强迫MySQL只对从内部select检索到的40条记录进行排序

我真的不明白一件事。MySQL无法在按分组之前按总计排序。。那么，是什么让查询变得如此缓慢呢

在本例中，我可以使用第二个查询，但如果我有另一个内部SQL，MySQL将开始创建临时表，这可能会降低性能，甚至超过ORDER BY。另一个“问题”是我使用ORM，而使用原始SQL真的很痛苦

谢谢你的建议

编辑：

带订单的执行计划

无订单执行计划

---

我可以在执行计划中看到，在使用ORDER BY时，有额外的filesort+临时文件。

我发现这很奇怪——除非在其中一个表中有一个名为

total

的列混淆了

ORDER BY

。我在Oracle中也有类似的问题。由于某种原因，添加订单执行了完整的表格扫描。检查你的执行计划。不过，您使用内部查询的解决方案非常好。@GordonLinoff为了可读性，我使用了这个标记。事实上，ORM是自己创建别名的——在本例中，它是“sclr_13”，实际上不在任何表中：-）。但好的一点以后可能会有用：-）@RobertKock。这是令人惊讶的，因为

ORDER BY

位于计算列上。它必须在聚合之后进行计算，所以我想不出执行计划会有什么不同。这就是为什么我说这是令人惊讶的。我也很惊讶。比较第一个查询的执行计划（有和没有order by）。