EF Core 中针对外部表查询的性能优化方案

在 EF Core 项目中，当使用 SQL Azure 数据库时，OPENJSON 技术通常能显著提升 Contains 查询的性能。但在某些特定场景下，特别是涉及外部表查询时，这种优化反而会导致性能问题。

问题背景

EF Core 在较新版本中引入了一项优化：对于包含 Contains 操作的查询（如 Where(x => values.Contains(x.Id))），会将其转换为使用 OPENJSON 的 SQL 语句。这种转换在大多数情况下能带来性能提升，因为：

1. 避免了参数化查询中的参数数量限制
2. 优化了查询计划缓存
3. 提高了大数据量下的查询效率

然而，当查询涉及外部表（External Tables）时，OPENJSON 操作不会在远程数据库执行，而是会将整个外部表数据拉取到本地进行处理。对于包含数百万行数据的外部表，这会导致大量数据传输，最终引发查询超时。

典型场景

考虑以下简单查询：

var results = dbContext.ExternalTable
    .Where(x => new[] { v1, v2 }.Contains(x.Id))
    .Select(x => new { x.Column1, x.Column2 })
    .ToList();

在正常情况下，EF Core 会生成类似这样的 SQL：

SELECT c1, c2 FROM ext.t1 WHERE Id IN (v1, v2)

但启用 OPENJSON 优化后，生成的 SQL 会变为：

SELECT c1, c2 FROM ext.t1 WHERE Id IN (SELECT value FROM OPENJSON(@p0) WITH ([value] int '$'))

对于外部表，这种转换会导致性能问题。

解决方案

EF Core 提供了针对单个查询禁用 OPENJSON 优化的方法：使用 EF.Constant 方法。修改后的查询如下：

var values = new[] { v1, v2 };
var results = dbContext.ExternalTable
    .Where(x => EF.Constant(values).Contains(x.Id))
    .Select(x => new { x.Column1, x.Column2 })
    .ToList();

这种方法会强制 EF Core 使用传统的 IN 子句而不是 OPENJSON，从而避免外部表查询时的性能问题。

实施建议

1. 性能分析：首先确认性能问题确实是由 OPENJSON 与外部表的交互引起
2. 局部优化：仅对确实需要的外部表查询使用 EF.Constant，保持其他查询继续享受 OPENJSON 带来的性能优势
3. 兼容性考虑：不需要为了这个问题而降低整个数据库的兼容性级别
4. 代码注释：对使用 EF.Constant 的地方添加注释，说明原因，便于后续维护

总结

EF Core 的查询优化功能在大多数场景下都能提升性能，但在特定情况下可能需要手动调整。理解这些优化机制的工作原理，并掌握像 EF.Constant 这样的工具方法，可以帮助开发者在保持整体性能的同时解决边缘情况的问题。这种精细化的性能调优能力是高效使用 ORM 框架的重要技能。