Azure SQL+EF场景：读取新范围数据时“NOT IN”与全量读取孰快？

场景回顾 #

你实现了一个地图事件展示功能：用户缩放或滚动地图时，新视图范围会包含部分已加载的旧数据。当前已读取1000条记录，新范围总共需要1500条数据（其中500条为新增）。数据结构包含72列（多为中等长度字符串、7个datetime类型、约10个int类型、1个byte[]类型的RowVersion），地理定位列是NetTopologySuite.Geometries.Point，基于Entity Framework和Azure SQL数据库。

现在对比两种加载方式的性能：

• 方式1：用NOT IN传入1000个已读ID，仅读取500条新记录
• 方式2：直接读取新范围内的全部1500条记录（包含已读的1000条）

两种方式的性能分析 #

方式1：增量读取（NOT IN 排除已读ID）

• 查询执行开销：当NOT IN子句包含1000个ID时，SQL查询的过滤逻辑会显著复杂化。数据库需要将每条候选记录的ID与这1000个值逐一匹配，即便ID列有索引，大量值的匹配也会增加查询计划的执行时间。再叠加原本的地理范围过滤（Distance计算），双重过滤会进一步提升数据库的计算负载。
• 网络传输：仅传输500条记录，数据量更小，但EF生成的SQL语句会因包含1000个ID而变长，不过这部分额外的SQL文本传输开销通常远小于数据本身的传输量，可忽略不计。
• 客户端逻辑：无需去重，但需要维护已读ID列表，增加了客户端状态管理的复杂度。

方式2：全量读取（直接查询新范围所有数据）

• 查询执行开销：仅执行地理范围过滤，逻辑更简单。如果Address.Location列创建了空间索引，Azure SQL能高效利用索引快速定位范围内的点，查询执行速度会显著快于带NOT IN的复杂查询——空间索引是优化这类地理查询的核心。
• 网络传输：传输1500条记录，比增量多500条，但现代网络环境下，这部分额外的数据传输开销通常远低于数据库端复杂查询的时间成本。
• 客户端逻辑：需要在内存中对已读记录去重，但这个操作成本极低（比如用HashSet存储已读ID，遍历新记录时过滤），几乎不会影响客户端性能。

结论与建议 #

1. 优先选择全量读取：在你的场景下，全量读取的整体性能更优。原因在于：
   • 地理空间查询是Azure SQL的强项，叠加NOT IN会增加查询复杂度，抵消增量传输的优势。
   • 空间索引能极大提升范围查询效率，全量查询的执行时间通常远短于带NOT IN的查询。
   • 客户端去重的成本可以忽略，且逻辑简单。
2. 必须优化空间索引：确保Address.Location列创建了适配点数据的空间索引，这是提升地理查询性能的关键。Azure SQL支持针对GEOMETRY类型的点数据创建高效的空间索引，能大幅减少范围查询的执行时间。
3. 特殊场景才考虑增量：只有当单条记录体积极大（比如包含大段二进制数据）且新增数据占比极低时，增量读取的传输优势才可能超过查询复杂度的开销，但你的场景不满足这个条件。

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