看起来是这样，但我找不到有关该主题的任何明确文档。
我要问的是这个查询的结果是否：
from x
in Db.Items
join y in Db.Sales on x.Id equals y.ItemId
group x by x.Id into g
orderby g.Count() descending
select g.First()
始终与以下查询相同：
from x
in Db.Items
join y in Db.Sales on x.Id equals y.ItemId
group x by x.Id into g
select g.First()
请注意，第二个查询让 Linq 决定组的顺序，第一个查询将其设置为已售出的数量，从最多到最少。
我的临时测试似乎表明 Linq 以这种方式自动对组进行排序，而文档似乎表明情况正好相反——项目按照它们在选择中出现的顺序返回。我想如果它以这种方式排序，添加额外的排序是没有意义的并且会浪费循环，最好不要这样做。
您可能会看到这一点，因为从 sqlserver 返回的查询结果在您的测试中始终处于相同的顺序。然而，这是一个谬误：根据定义，SQL 中的集合没有顺序，除非它用 ORDER BY 明确指定。因此，如果您的查询没有 order by 语句，您的集合可能看起来像是已排序的，但事实并非如此，可能是在边缘情况下，顺序不同（例如，当服务器必须加载由于内存限制或其他原因，表的顺序不同）。所以经验法则：如果你想要一个订单，你必须指定一个。
LINQ 分组不保证这样的事情。虽然它可能适用于该特定情况，但它可能不适用于另一种情况。避免依赖这种副作用。
顺便说一句，如果由于聚集索引或其他原因，SQL Server 真的有意对输出进行排序，添加ORDER BY子句不会有任何伤害，因为查询优化器应该足够聪明，知道结果已经排序，所以你不会丢失任何事物。
如果规格不能保证订购，您应该认为它是偶然的，并且可能会随软件的任何新版本而变化。
不要把它拿出来，除非
a）您已经测量了它并且它产生了显着差异
b) 在您的软件环境发生微小变化后，您愿意监控、测试和更改（无处不在）。