LINQ查询中调换Distinct()与OrderBy()的调用顺序是否会影响性能？

这是个非常实用的问题——很多开发者在写LINQ查询时容易忽略操作顺序带来的性能差异，尤其结合延迟执行特性来看，这里的门道还不少。咱们来逐个拆解你的疑问：

关于延迟执行的理解：你是对的！ #

首先要肯定你的认知：构建LINQ查询时，比如写MyList.Distinct().OrderBy(x => x)，本质上只是创建了一棵描述查询逻辑的表达式树，此时完全没有执行任何实际的数据操作——这就是LINQ的延迟执行特性。只有当你调用ToList()、ToArray()或者开始枚举（比如foreach遍历）时，查询才会被真正执行。

不过这里要补充一点：运行时或查询提供者（比如EF Core）的优化能力是有限的，不是所有操作顺序都会被自动调整到最优。

两种场景下的性能差异 #

接下来分两种最常见的LINQ使用场景来分析：

1. LINQ to Objects（内存中操作集合） #

你提到Distinct()在内存中会用哈希表来实现，这点完全正确——它通过哈希表来跟踪已出现的元素，平均时间复杂度是O(n)（n为原集合大小）。这时候操作顺序的差异会非常明显：

• Distinct().OrderBy()：先对原集合去重，得到一个元素数量远小于原集合的新集合（假设原集合有大量重复元素），再对这个小集合执行排序（时间复杂度O(k log k)，k为去重后的元素数）。
• OrderBy().Distinct()：先对整个原集合排序（O(n log n)，n是原集合大小），再去重。虽然排序后相同元素相邻，去重可以线性完成，但排序的开销已经远大于先去重再排序的情况——尤其当原集合重复元素较多时，这个性能差距会被放大。

举个直观的例子：如果原集合有10000个元素，其中9000个是重复的，先去重后只剩1000个元素需要排序，显然比先排序10000个元素再去重高效得多。

2. LINQ to SQL/EF Core（数据库查询） #

你假设“.NET会在执行前优化SQL查询”，这个说法部分正确，但不能完全依赖：

• 当你写Distinct().OrderBy()时，EF Core这类查询提供者会将其转换为SELECT DISTINCT ... ORDER BY ...的SQL语句，数据库引擎会按照最优方式执行（通常是先去重再排序，或者根据索引优化）。
• 如果你写OrderBy().Distinct()，虽然部分数据库（比如SQL Server）可能会在内部调整执行顺序，但并非所有数据库或所有场景都会这么做——有些情况会先执行排序再去重，这就带来了额外的排序开销。

更重要的是，ORDER BY和DISTINCT在SQL中有语法限制（比如ORDER BY的列必须包含在SELECT DISTINCT的列中），如果你的查询逻辑允许，优先写Distinct().OrderBy()不仅逻辑更清晰，也能避免依赖数据库的自动优化。

总结你的假设 #

你的“两者执行速度无差异”的假设是不准确的：

• 在LINQ to Objects场景下，操作顺序对性能影响极大，Distinct().OrderBy()明显更优；
• 在数据库查询场景下，虽然部分情况会被优化，但主动选择更合理的操作顺序能确保性能最优，同时避免潜在的兼容性问题。

内容的提问来源于stack exchange，提问作者Wim ten Brink