性能对比：.ToList().Distinct()与.Distinct().ToList()该如何选择？

这问题问得挺实在的，刚好日常开发里经常会碰到类似的选择，咱们从执行逻辑、SQL生成、性能和优缺点几个维度聊清楚：

核心差异：执行时机完全不同 #

这俩写法的本质区别在于去重操作发生的位置：

• ToList().Distinct()：先通过ToList()触发数据库查询，把所有符合条件的数据全量加载到内存中，再用LINQ to Objects在内存里完成去重。
• Distinct().ToList()：先把Distinct的逻辑推送给数据库（如果用的是EF这类ORM），让数据库先完成去重，再把去重后的结果加载到内存转成List。

SQL查询是否相同？答案是：完全不同 #

这里要分场景看：

• ORM场景（比如EF Core）：
  • Distinct().ToList()会生成带DISTINCT关键字的SQL，数据库层面直接返回去重后的结果。
  • ToList().Distinct()的SQL就是普通的SELECT语句，不带DISTINCT，数据库会返回所有符合条件的数据，去重完全在内存里做。
• 内存集合场景（比如直接对List调用）：
  不存在SQL，但执行逻辑还是前者先加载全量再去重，后者先去重再转List，本质都是LINQ to Objects操作。

性能谁更优？大部分场景下Distinct().ToList()完胜 #

没错，你感觉第二种性能更优是对的，原因很直接：

• 数据库的强项就是数据处理，尤其是带索引的情况下，DISTINCT操作的效率远高于内存里遍历全量数据去重。
• 更关键的是，数据库去重后返回的数据量更少，大幅减少了网络传输的耗时，同时也降低了应用服务器的内存占用。
• 只有当数据量极小（比如几十条）时，两者的性能差异可以忽略不计；但数据量越大，Distinct().ToList()的优势越明显。
• 极端反例：如果数据库没有合适的索引，导致DISTINCT执行很慢，而内存去重反而更快？这种情况极少，通常是数据库设计有问题，优先应该优化数据库索引，而不是换写法。

两种写法的优缺点对比 #

Distinct().ToList() #

优点：

• 遵循“让数据库做擅长的事”的最佳实践，性能更优，资源占用更低。
• 减少不必要的数据传输，降低应用服务器的内存压力。

缺点：

• 依赖ORM对Distinct的SQL转换能力，如果是复杂类型或自定义去重规则（比如自定义IEqualityComparer），ORM可能无法转换，会 fallback到内存去重（等于变相变成了ToList().Distinct()）。
• 无法先在内存里做自定义处理再去重，灵活性稍差。

ToList().Distinct() #

优点：

• 灵活性拉满：可以先把数据加载到内存，做各种自定义操作（比如复杂过滤、字段转换），再执行去重。
• 支持自定义IEqualityComparer实现复杂去重逻辑，不受数据库限制。

缺点：

• 数据量大时性能拉胯，全量加载数据会导致内存占用飙升，网络传输耗时增加，容易引发性能瓶颈。
• 不符合性能优化的最佳实践，长期来看可能会埋下隐患。

额外注意点 #

如果你的去重逻辑依赖自定义的IEqualityComparer，那不管哪种写法，Distinct都会在内存里执行——因为数据库无法理解自定义的比较规则。这时候两种写法的差异就只是“先转List还是先去重”，但本质都是内存操作，性能差异不大。

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