Linq To DB 查询缓存与动态查询过滤器的问题分析

问题背景

在使用 Linq To DB 5.4.1 版本时，发现了一个关于查询缓存与动态查询过滤器(query filter)交互的问题。当为实体定义查询过滤器时，过滤器函数(Func)的内容仅在第一次执行时被真正使用，后续查询虽然会执行过滤器函数，但在生成SQL时却仍然使用第一次缓存的结果。

问题重现

通过一个简单的示例可以清晰地重现这个问题。示例中定义了一个查询过滤器，该过滤器使用 Random 生成随机数作为查询条件的一部分。每次执行查询时，虽然控制台会输出新的随机数(证明过滤器函数被执行)，但当查询缓存启用时，生成的SQL语句却始终包含第一次生成的随机数。

// 示例代码展示了问题现象
var isCacheEnabled = true;
using var dbCtx = new MyDbCtx(new DataOptions(new ConnectionOptions()
{
    ConnectionString = "Data Source=:memory:;Version=3;New=True;",
    ProviderName = ProviderName.SQLite
}).UseDisableQueryCache(!isCacheEnabled));

// 定义带有随机数条件的查询过滤器
builder.Entity<User>().HasQueryFilter((q, ctx) =>
{
    var r = Random.Shared.Next();
    Console.WriteLine(r); // 每次都会输出新随机数
    return q.Where(x => x.Name.Contains(r.ToString()));
});

技术分析

这个问题本质上源于 Linq To DB 的查询缓存机制与动态查询过滤器的交互方式。当查询缓存启用时：

1. 第一次查询执行时，系统会完整解析查询表达式树，包括查询过滤器中的条件，并生成对应的SQL语句，同时缓存这个解析结果。

2. 后续查询执行时，虽然查询过滤器函数会被调用(因此会看到新的随机数输出)，但系统直接从缓存中获取之前解析好的SQL语句，不再重新解析包含新随机数的完整表达式树。

3. 当查询缓存禁用时，每次查询都会完整解析表达式树，因此会包含最新的随机数条件。

解决方案与建议

Linq To DB 团队已经确认这个问题将在 6.0.0 版本中修复。但在等待修复的同时，开发者可以考虑以下建议：

1. 避免高度动态的查询过滤器：即使问题修复后，过于动态的查询过滤器也会导致查询缓存频繁失效，影响性能。

2. 合理使用查询缓存：对于确实需要动态过滤的场景，可以针对性地禁用查询缓存，而不是全局禁用。

3. 考虑替代方案：对于权限过滤等常见需求，可以考虑使用视图、存储过程或应用层过滤等替代方案。

实际应用场景

这个问题在实现多租户、行级安全或基于权限的数据过滤时尤为明显。例如，当需要根据当前用户权限动态过滤数据时，开发者可能会尝试在查询过滤器中加入权限检查逻辑，但会遇到类似问题。

正确的做法应该是将这类动态参数通过外部方式(如参数)传入查询，而不是依赖查询过滤器内部的随机或动态生成值。这不仅能避免缓存问题，也能使查询意图更加清晰。

总结

Linq To DB 的查询缓存机制在大多数情况下能显著提升性能，但在与动态查询过滤器交互时存在这个边界情况。开发者在使用动态查询条件时需要特别注意这个问题，合理设计数据访问层，平衡动态性与性能的需求。随着 6.0.0 版本的发布，这个问题将得到根本解决，但理解其背后的机制对于编写高效、可靠的数据库访问代码仍然非常重要。