Django聚合查询异常：添加order_by后结果符合预期的原因

这是个非常典型的Django ORM踩坑点，我来一步步拆解你的疑问：

为什么添加order_by("user_id")会返回每个用户的最小duration记录？ #

核心原因在于Django ORM的默认排序会偷偷修改你的分组依据：

如果你的Activity模型在Meta类中定义了ordering字段（比如按创建时间、更新时间排序），Django会自动把这个默认排序字段加入到GROUP BY子句中。这就导致你的分组逻辑从「按user_id分组」变成了「按user_id + 默认排序字段分组」。

举个例子，假设你的模型默认按created_at排序，那没加order_by时生成的SQL大概是这样：

SELECT user_id, MIN(duration) AS duration__min
FROM activity
GROUP BY user_id, created_at  -- 多了默认排序字段created_at
ORDER BY created_at;

同一个user_id下，只要created_at不同，就会被分成不同的组，每个组都会计算一次min(duration)——这就是你看到同一个user_id对应多条min结果的原因。

而当你显式添加.order_by('user_id')时，你覆盖了模型的默认排序，此时GROUP BY子句只会保留你指定的user_id字段：

SELECT user_id, MIN(duration) AS duration__min
FROM activity
GROUP BY user_id
ORDER BY user_id;

这样每个唯一的user_id会被分到同一个组里，计算出来的就是该用户所有activity中的最小duration，自然就符合你的预期了。

为什么values子句在annotate之前，却没按唯一user_id返回聚合结果？ #

你说的没错：values()在annotate()之前时，确实是用来指定分组字段的。但问题出在Django的一个「隐式行为」上：

为了兼容SQL语法规则（有些数据库要求ORDER BY的字段必须出现在SELECT或GROUP BY中），Django会自动把模型默认排序的字段加入到GROUP BY和SELECT中，哪怕你没在values()里指定它。这就相当于偷偷给你的分组加了额外的字段，导致分组粒度变细，同一个user_id下出现了多个分组结果。

只有当你显式指定order_by()时，才会覆盖这个默认行为，让分组严格按照values()里指定的字段来进行。

总结一下避坑要点： #

• 使用values()+annotate()做分组聚合时，一定要检查模型的Meta.ordering是否会影响分组结果；
• 如果出现分组结果不符合预期，优先显式指定order_by()，确保分组逻辑只受你指定的字段控制；
• 也可以在查询中添加.order_by()（空括号）来完全取消排序，同样能避免默认排序字段干扰分组：

  activities.values('user_id').annotate(Min('duration')).order_by()
  

内容的提问来源于stack exchange，提问作者tyjoo