EF Core 5 基于实体属性筛选内存列表查询翻译失败如何解决

EF Core 5的查询翻译器不支持在服务端查询投影中，直接对内存持有的本地集合执行FirstOrDefault+Contains的遍历匹配逻辑。这类操作会被识别为需要客户端评估的逻辑，如果后续拼接GroupBy等需要在数据库端执行的操作，会直接抛出翻译异常。

方案1：动态拼接查询表达式（推荐） #

完全在数据库端执行，性能最优，支持后续任意GroupBy/Where/OrderBy等EF查询操作，不会产生额外的客户端数据拉取开销。
如果不想手写表达式树，可以借助LINQKit（EF Core 5兼容）简化实现，生成的SQL会自动转换为多段LIKE匹配的CASE WHEN逻辑，和你预期的FirstOrDefault匹配优先级完全一致：

// 需先安装Nuget包：LINQKit.Microsoft.EntityFrameworkCore
var toCheckSimilarSongs = new List<string>() { "Highway to hell", "Nothing else matters" };
var songsSet = Context.ReadSet<Song>().AsExpandable();

// 动态拼接匹配逻辑
Expression<Func<Song, string>> matchKeywordExpr = s => null;
foreach (var keyword in toCheckSimilarSongs)
{
    var currentKw = keyword;
    matchKeywordExpr = matchKeywordExpr.Or(s => 
        s.Name.Contains(currentKw) ? currentKw : null
    );
}

// 最终查询可直接拼接后续GroupBy等操作，全量翻译为SQL执行
var similarSongs = songsSet.Select(song => new
{
    Name = song.Name,
    ToCheckSimilarSong = matchKeywordExpr.Invoke(song)
});

生成的对应SQL逻辑如下：

SELECT [s].[Name],
    CASE
        WHEN [s].[Name] LIKE N'%Highway to hell%' THEN N'Highway to hell'
        WHEN [s].[Name] LIKE N'%Nothing else matters%' THEN N'Nothing else matters'
        ELSE NULL
    END AS [ToCheckSimilarSong]
FROM [Songs] AS [s]

方案2：先过滤再内存投影（开发成本最低） #

适合歌曲表数据量不大、匹配结果集量级在万级以下的场景，不需要引入额外依赖，代码可读性最高：

var toCheckSimilarSongs = new List<string>() { "Highway to hell", "Nothing else matters" };
// 第一步：EF Core可正常翻译Any+Contains逻辑，在数据库端过滤出所有匹配任意关键词的歌曲
var matchedRawSongs = Context.ReadSet<Song>()
    .Where(s => toCheckSimilarSongs.Any(kw => s.Name.Contains(kw)))
    .ToList();
// 第二步：在内存中完成关键词匹配投影，后续GroupBy等操作直接在内存集合上执行即可
var similarSongs = matchedRawSongs.Select(song => new
{
    Name = song.Name,
    ToCheckSimilarSong = toCheckSimilarSongs.FirstOrDefault(kw => song.Name.Contains(kw))
});

注意：该方案会把所有匹配到的歌曲完整字段拉取到应用内存，超大数据量场景下不适用。

方案3：全文索引优化（超大数据量场景适用） #

如果歌曲表数据量超过10万级，LIKE '%关键词%'会触发全表扫描，查询性能很差。可以给Name字段配置数据库全文索引，将普通字符串Contains替换为EF Core提供的全文检索方法EF.Functions.Contains，其余逻辑和方案1一致，查询性能可提升1~2个数量级。

• 常规业务场景优先选方案1，兼顾性能、灵活性和开发效率
• 小项目、数据量低选方案2，写起来最快
• 数据量高、模糊匹配是高频场景选方案3，从数据库层面优化性能

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