“不在列表中”比重新阅读更快吗？

Question

我有一个地图显示存在于地图范围内的相关事件。当用户缩小时，现在有更多事件，基本上在一个更大的框中，其中包括已经显示的内部框。

所以它首先显示丹佛市中心。缩小，现在是丹佛地铁。再缩小一些，我们现在看到丹佛周围的农村地区。此时，较大框中显示的 95% 内容都显示在较小的框中。

读取的记录有72列，大部分是中等长度的字符串，7个是日期时间，大约10个是整数。唯一的 byte[] 是 RowVersion。地图上还有一个地理栏位。

当我阅读一个新的更大的框时，以及当用户横向滚动移动框但新框包含旧框的一部分时，哪个更快。

假设我已读取 1,000 条记录。现在它将读取 500 条新记录或 1,500 条总记录。通常，执行“不在列表中”并为其提供 1,000 个 ID（整数）的列表会更快吗？或者更快地阅读所有内容，包括重新阅读我已经拥有的内容？

更新：根据@Charlieface的评论，我将事件位置作为记录中的一列。它是一个

NetTopologySuite.Geometries.Point

，我使用它如下：

public static IQueryable<Event> WhereWithinRange(this IQueryable<Event> source, Point? location, int distance)
{

    if (location == null)
        return source;

    var meters = MiscUtils.MilesToMeters(distance);
    var query = source
        .Where(e =>
            e.Address.Location == null
            || e.Address.Location.Distance(location) < meters);
    return query;
}

如果重要的话，这是 Azure SQL 数据库上的实体框架。

ps - 是的，我可以测试自己，但是有谎言，该死的，谎言和统计数据。我在这里请求比我更了解 SQL 性能并且已经准确测试过这一点的人。

Answer 1

从性能角度来看，与添加排除列表相比，执行完整检索的查询速度会一样快或更快，因为排除查询的执行计划的第一部分仍将涉及检查索引/表以了解数据最初需要的内容被纳入/考虑。潜在节省时间的地方在于结果数据的传输和具体化。发送和构建 1000 个实体/视图模型将比 1500 个快一点。

但是，您应该考虑的一个限制是，您可以传递以在生成的

NOT IN(...)

表达式中使用的 PK 数量是有限的。对于 SQL Server 来说大约是 32k，而 Oracle 似乎是 1000，因此每个 DBMS 可能有不同的限制。在任何一种情况下，如果值足够，性能可能会降低到超过传输和物化所节省的任何成本，并且超过某个点将导致异常。

为了最大限度地提高查询此类数据集的性能，我的建议是：

#1。利用投影来最大程度地减少数据传输/具体化：要渲染地图或位置摘要列表，您几乎肯定不需要 72 列数据。使用

Select()

只挑选您实际需要的列，您可以在需要时通过 ID 获取完整位置。投影的额外好处是 DbContext 不会缓存/跟踪返回的数据。获取实体意味着默认情况下 DbContext 将每个实体添加到其更改跟踪缓存中。这会导致内存膨胀并影响所有后续查询的性能。投影不会被缓存。

#2。建立预测后，分析执行计划并调整数据库索引，以确保该查询高效运行：像任何数据库系统一样使用 EF 查询的一个技巧是检查实际执行情况并根据频繁运行的查询调整索引和/或跨越大量数据。

#3，当通过 ID 获取完整实体以获取只读详细信息时，请使用

AsNoTracking()

：当您需要对实体本身进行读取访问（例如选定条目的详细信息视图）时，读取实体而不将它们添加到跟踪缓存中。很多时候，当开发人员面临性能问题时，他们会被引导查看更改跟踪缓存并选择完全禁用它“以提高性能”。更改跟踪缓存对于编辑非常有用，不应完全禁用，因此读取操作应尽可能使用投影来提高性能，并且在只读操作需要整个实体的少数情况下，请使用

AsNoTracking()

该特定查询。

加载地图位置的数千个摘要视图模型对于 EF 来说应该完全没有问题，并且不需要考虑排除因素的复杂计划。作为一般建议，我会避免过早优化的诱惑。从最简单的事情开始，评估并在出现问题时进行调整。重要的是尽早使用真实世界规模的数据进行测试以解决问题，而不是试图预测问题可能出现在哪里，这可能会导致寻找问题的解决方案，从而导致不同的、可以避免的问题。