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

在 EF Core 8.0.12 版本中，开发人员发现了一个与查询过滤器相关的性能回归问题。这个问题主要出现在使用动态函数调用返回集合值，并在查询过滤器中应用 Contains 操作时。

问题背景

在 EF Core 6.0.16 版本中，当开发人员在查询过滤器中定义一个动态函数调用，该函数返回一个集合值，然后使用 Contains 方法来过滤实体时，EF Core 会生成一个简单的 IN 子句。例如：

modelBuilder.Entity<MyEntity>()
    .HasQueryFilter(entity =>
         myService.GetUserScopesData(PERMISSION)
                  .UserScopesInfo.Select(s => s.ScopeValue)
                  .Contains(entity.ScopeValue));

在 EF Core 6.0.16 中，这会生成类似以下的 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 子句开销更大。

技术分析

这个变化源于 EF Core 8.0 对参数化集合处理方式的改进。EF Core 团队引入了使用 OPENJSON 来处理参数化集合的功能，目的是为了支持更大的参数集合和更复杂的场景。然而，这种改变在某些简单场景下反而带来了性能开销。

解决方案

对于遇到此问题的开发者，EF Core 团队提供了以下解决方案：

1. 在 EF Core 9.0 及以上版本，可以使用 TranslateParameterizedCollectionsToConstants 配置选项来恢复旧行为：

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

2. 对于 EF Core 8.0 用户，目前没有直接的修复方案。EF Core 团队建议等待 EF Core 10 的发布，届时可能会默认恢复旧行为。

最佳实践建议

1. 对于性能敏感的查询，考虑将动态获取的集合值缓存起来，而不是每次都从服务中获取。

2. 评估是否可以将查询过滤器重构为使用静态值，或者通过其他方式实现相同的过滤逻辑。

3. 如果必须使用动态函数调用，考虑在应用层实现过滤逻辑，而不是依赖查询过滤器。

4. 监控查询性能，特别是在升级 EF Core 版本后，确保没有意外的性能退化。

总结

EF Core 8.0 引入的 OPENJSON 处理方式虽然在某些场景下提供了优势，但在简单的 IN 子句场景下可能导致性能下降。开发者应该了解这一变化，并根据自己的应用场景选择合适的解决方案。EF Core 团队已经意识到这个问题，并计划在未来的版本中提供更好的默认行为。