在 EF Core 应用中，每一次查询默认都会走到数据库执行。当系统存在大量重复读取、且数据变化不频繁时，这种机制会给数据库带来不必要的压力。二级缓存指的是在 DbContext 之外、跨请求保存查询结果的能力，使得相同查询在有效期内直接命中内存或分布式缓存，从而降低数据库负载并提升响应速度。
为什么需要 EF Core 二级缓存
EF Core 自带的查询编译缓存只能避免反复解析 LINQ 表达式树，并不会缓存查询结果本身。也就是说，即便你执行完全相同的查询，它依旧会向数据库发送 SQL。对于报表类、配置类或字典类数据，这种重复查询非常浪费资源。
引入二级缓存后，我们可以将查询结果的序列化副本保存在进程内或 Redis 中。下次遇到相同查询时，直接反序列化返回，跳过数据库访问。这在高并发只读场景中能显著降低延迟，也能减少数据库连接消耗。
使用 EFCoreSecondLevelCacheInterceptor 实现
社区中比较成熟的方案是 EFCoreSecondLevelCacheInterceptor。它通过 EF Core 的拦截器机制，在查询执行前后插入缓存逻辑。我们只需要在服务注册时配置缓存提供方和过期策略即可，对业务代码侵入很小。
下面以 MemoryCache 为例，展示如何在 ASP.NET Core 中接入该库。注意代码中的特殊字符已做转义处理。
// 安装包：EFCoreSecondLevelCacheInterceptor、Microsoft.Extensions.Caching.Memory
using Microsoft.Extensions.Caching.Memory;
using EFCoreSecondLevelCacheInterceptor;
public void ConfigureServices(IServiceCollection services)
{
var cacheOptions = new MemoryCacheOptions();
services.AddSingleton(new MemoryCache(cacheOptions));
services.AddDbContext<MyDbContext>(options =>
{
options.UseSqlServer("Server=.;Database=Test;Trusted_Connection=true;");
options.AddInterceptors(new SecondLevelCacheInterceptor());
});
services.AddSecondLevelCache(options =>
{
options.UseMemoryCacheProvider();
options.CacheAllQueries(CacheExpirationMode.Sliding, TimeSpan.FromMinutes(5));
});
}
在查询时，我们可以通过扩展方法显式标记需要缓存的查询，也可以配置全局缓存。该库会自动根据表名生成缓存依赖，当对应表发生增删改时清理相关缓存，避免脏数据。
var list = await dbContext.Products
.Where(p => p.IsActive)
.Cacheable()
.ToListAsync();
手动封装二级缓存逻辑
如果不希望引入第三方库，也可以自己写一层简单的缓存包装。核心思路是：以查询条件生成稳定 key，优先读缓存，未命中再执行 EF 查询并回写。
以下示例演示了基于 IMemoryCache 的手动方案。实际项目中可以把 key 生成逻辑抽象为工具类，并增加分布式锁防止缓存击穿。
public async Task<List<Product>> GetActiveProductsAsync(IMemoryCache cache, MyDbContext db)
{
string key = "active_products";
if (cache.TryGetValue(key, out List<Product> cached))
{
return cached;
}
var data = await db.Products.Where(p => p.IsActive).ToListAsync();
cache.Set(key, data, TimeSpan.FromMinutes(10));
return data;
}
手动方案灵活但容易遗漏失效处理。如果某商品状态变更，必须手动删除 key，否则会返回旧数据。因此建议在写操作时统一调用缓存清理方法，或借助 EF 的 SavingChanges 事件自动失效。
缓存策略与注意事项
无论采用哪种方案，都要明确缓存粒度与过期时间。对于变化频繁的数据，缓存时间应较短；对于几乎不变的字典表，可设置较长滑动过期。同时应关注缓存穿透问题，对空结果也做短暂缓存。
在分布式部署环境中，进程内缓存会导致各节点数据不一致，此时应改用 Redis 等共享缓存。EFCoreSecondLevelCacheInterceptor 支持 Redis 提供方，手动方案也可替换为 IDistributedCache 接口实现。
| 方案 | 侵入性 | 失效管理 | 适用场景 |
|---|---|---|---|
| 拦截器库 | 低 | 自动按表失效 | 通用 Web 应用 |
| 手动封装 | 中 | 需自行处理 | 简单或定制需求 |
| Redis 分布式 | 低/中 | 依赖提供方 | 多节点集群 |
综上所述，EF Core 二级缓存并不复杂，关键在于选对工具并设计合理的失效机制。对于大多数项目，直接使用拦截器库能快速获得稳定收益；对缓存逻辑有强定制诉求时，再考虑手动实现。