System.Linq.Dynamic.Core 在 EF Core 8.0 中的性能问题分析与解决方案

System.Linq.Dynamic.Core 是一个流行的动态 LINQ 查询库，它为开发者提供了在运行时构建 LINQ 查询的能力。然而，在 EF Core 8.0 环境下使用该库时，用户报告了显著的性能问题，特别是在首次执行包含排序操作的查询时，即使处理的数据量很小，也可能出现超过一分钟的延迟。

问题现象

当开发者将项目升级到 EF Core 8.0 并使用 Microsoft.EntityFrameworkCore.DynamicLinq 8.3.10 版本时，发现以下特征：

1. 任何包含 OrderBy 操作的查询首次执行时都会出现明显延迟
2. 即使查询结果集非常小（如仅包含一条记录），也会出现此问题
3. 后续查询执行速度恢复正常
4. 在 .NET 6.0 环境下相同代码没有此问题

问题根源分析

经过技术团队深入调查，发现问题主要源于 System.Linq.Dynamic.Core 的类型发现机制。该库默认会扫描所有已加载程序集来查找可能用于动态 LINQ 查询的类型。具体表现为：

1. 程序集扫描开销：DefaultDynamicLinqCustomTypeProvider 会加载并扫描所有引用程序集
2. 首次执行延迟：首次查询时需要完成类型发现和缓存构建
3. EF Core 8.0 变化：EF Core 8.0 可能引入了额外的程序集或改变了加载机制，加剧了扫描负担

解决方案

1. 自定义类型提供程序

最有效的解决方案是实现自定义的 IDynamicLinqCustomTypeProvider，精确控制需要扫描的程序集范围：

public class CustomDynamicLinqTypeProvider : IDynamicLinqCustomTypeProvider
{
    public HashSet<Type> GetCustomTypes()
    {
        // 仅返回必要的类型集合
        return new HashSet<Type>
        {
            typeof(MyEntityType1),
            typeof(MyEntityType2)
        };
    }

    public Dictionary<Type, List<Type>> GetCustomTypeProviderTypes()
    {
        // 返回空字典或必要的类型映射
        return new Dictionary<Type, List<Type>>();
    }
}

2. 配置优化

在应用启动时配置动态 LINQ 使用自定义类型提供程序：

var config = new ParsingConfig
{
    CustomTypeProvider = new CustomDynamicLinqTypeProvider()
};

// 在查询中使用配置
var query = dbContext.Entities
    .AsQueryable()
    .OrderBy(config, "PropertyName");

3. 预热策略

对于无法立即实施自定义类型提供程序的情况，可以考虑在应用启动时执行一次"预热"查询：

// 应用启动时执行
var _ = dbContext.Entities.Take(1).OrderBy("Id").ToList();

性能对比

技术团队通过测试项目验证了优化效果：

环境	首次查询时间	后续查询时间
.NET 6.0	~1400ms	~5ms
.NET 8.0	~1060ms	~6ms
自定义提供程序	<100ms	~5ms

最佳实践建议

1. 最小化扫描范围：在自定义类型提供程序中仅包含确实需要用于动态查询的类型
2. 按需加载：对于大型项目，考虑按模块/功能动态加载类型
3. 监控性能：在生产环境监控动态查询性能，特别是应用更新后
4. 版本适配：关注 System.Linq.Dynamic.Core 的更新，及时获取性能改进

通过实施这些优化措施，开发者可以显著改善在 EF Core 8.0 环境下使用动态 LINQ 查询的性能表现，特别是解决首次查询延迟过高的问题。