EntityFramework Core 8.0 中查询过滤器性能回归问题分析

在 EntityFramework Core 8.0.12 版本中，开发人员发现了一个与查询过滤器相关的性能回归问题。这个问题主要出现在使用动态函数调用返回集合值进行 Contains 操作时，EF Core 8.0 生成的 SQL 查询与之前版本有显著不同。

问题背景

在 EF Core 6.0.16 版本中，当开发者在查询过滤器中调用动态函数返回集合值，并使用 Contains 方法进行过滤时，EF Core 会生成使用 IN 子句的 SQL 查询。例如：

SELECT [r].[Id]
FROM [Tenant1].[MyEntity] AS [r]
WHERE [r].[ScopeValue] IN (1, 2)

然而，在升级到 EF Core 8.0.12 后，同样的查询过滤器会生成使用 OPENJSON 的 SQL 查询：

SELECT [r].[Id]
FROM [Tenant1].[MyEntity] AS [r]
WHERE [r].[ScopeValue] IN (
    SELECT [e].[value]
    FROM OPENJSON(@__ef_filter__p_0) WITH ([value] int '$') AS [e]
)

技术影响

这种变化带来了明显的性能差异。OPENJSON 虽然在某些场景下有其优势，但在简单的值集合过滤场景中，性能通常不如直接的 IN 子句。这种性能回归对于依赖查询过滤器进行数据隔离的应用来说尤为明显。

解决方案

对于遇到此问题的开发者，目前有以下几种解决方案：

1. 升级到 EF Core 9.0 及以上版本：EF Core 9.0 引入了 TranslateParameterizedCollectionsToConstants 配置选项，可以恢复之前的 IN 子句行为：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder.UseSqlServer("...", o => o.TranslateParameterizedCollectionsToConstants());

2. 等待 EF Core 10.0 发布：根据官方反馈，EF Core 10.0 可能会默认恢复使用 IN 子句的行为。

3. 重构查询过滤器：考虑将动态获取的集合值预先获取并缓存，然后直接使用这些值构建查询。

技术建议

对于性能敏感的应用，建议：

• 在测试环境中充分评估 OPENJSON 与 IN 子句的性能差异
• 考虑使用 Dapper 等轻量级 ORM 执行关键路径上的查询
• 监控生产环境中的查询性能，特别是升级 EF Core 版本后

总结

EF Core 8.0 中查询过滤器生成的 SQL 从 IN 子句变为 OPENJSON 是一个需要注意的变化，特别是在性能敏感的场景中。开发者应该了解这一变化，并根据自己的应用场景选择合适的解决方案。随着 EF Core 的持续发展，这一问题有望在后续版本中得到更好的解决。