EF Core：FirstOrDefault() 与 SingleOrDefault() 性能比较

Question

我看到这些方法如何转换为 sql：

• FirstOrDefault()->Select TOP(1) ...
• SingleOrDefault()->Select TOP(2) ...

所以我有两个问题：

• 我们是否可以假设在仅一种现有结果场景中SingleOrDefault()扫描整个表并且比 慢大约 2 倍FirstOrDefault()？
• 有什么建议应该使用哪种方法吗？例如，当我们查询PK并确定只有一个结果时？

Answer 1

我们是否可以假设在仅一种现有结果场景中SingleOrDefault()扫描整个表并且比 慢大约 2 倍FirstOrDefault()？

这要看情况，所以一般不会。

对于唯一索引列标准（如 PK），这并不重要 - SQL 优化器足够智能，可以使用索引定义中有关值基数的信息。

对于其他人来说，它类似于 LINQ to Objects。一般来说（在没有值分布统计的情况下）数据库必须执行全表扫描。所以问题是它是否可以更早地停止搜索。如果不存在匹配项，则两个操作都是相同的 O(N)。如果项目存在，FirstOrDefault可以提前停止，同时SingleOrDefault应完成完整扫描。因此，这取决于匹配项与扫描“开始”的距离有多近，以及第二个匹配项是否存在以及它有多接近。如果只存在一个匹配值，我们可以预期后一种方法平均会慢 2 倍。

有什么建议应该使用哪种方法吗？例如，当我们通过PK查询并确定只有一个结果时？

这被认为是固执己见，但我想说FirstOrDefault——不仅仅是因为性能。SingleOrDefault在我看来，这是一个奇怪的方法，因为它有两个不同的目的——查找匹配项并验证不存在重复项。第二部分通常由内存中的属性数据结构和数据库中的唯一约束/索引来保证。

Find最后，由于在搜索 PK 时有一些关于该方法与上述两种方法的评论/讨论。该方法的主要目的Find是首先搜索本地缓存并从那里返回对象（如果存在）。如果没有，那么它会在内部执行 - FirstOrDefault。这应该可以回答 EF Core 团队认为更可取的问题。