EF Core中如何为静态查找联结表启用全局可复用缓存

核心思路：彻底将静态引用表的加载逻辑和业务表的关联查询解耦，从根源上避免带业务过滤条件的Join查询占用缓存、重复查库的问题，同时解决手动赋值导航属性导致的变更跟踪异常。

具体落地步骤（完全适配Redis+EF二级缓存的技术栈） #

• 第一步：为静态引用表搭建独立的全局缓存
  • 针对这类体量<100行、极少变更的引用表（示例中的Currency表）设置固定的全局缓存键（比如ref:currency:all），应用启动时就将全量数据加载到Redis中，后续仅在引用表本身发生变更时手动刷新缓存。
  • 缓存读取时使用AsNoTracking模式加载实体，避免单请求内的跟踪状态污染全局缓存的实体对象。
• 第二步：自动化将缓存实体挂载到当前DbContext，解决变更跟踪异常
  之前手动赋值导航属性触发“重复新增相同ID实体”报错的核心原因，是EF会将未经过上下文跟踪的实体默认标记为Added状态，提交变更时就会尝试插入重复主键的记录。只要在DbContext实例创建后，通过Attach方法将缓存的引用实体显式注册到跟踪器中，并将实体状态固定为Unchanged即可彻底解决这个问题：

  // 每个请求初始化DbContext时自动执行，可通过拦截器/自定义上下文构造函数实现
  var cachedCurrencies = _distributedCache.LoadFromCache("ref:currency:all");
  foreach (var currency in cachedCurrencies)
  {
      // 重复Attach同主键实体时EF会自动跳过，不会触发状态冲突
      _dbContext.Attach(currency);
  }
  

  这套逻辑完全可以下沉到基础设施层，对上层业务代码零侵入。
• 第三步：移除业务查询中对引用表的Include/Join逻辑
  原来的查询写法依赖Join把Currency数据拉进业务查询SQL：

  // 原写法：SQL与单个用户的查询条件强绑定，缓存无法全局复用
  var userBalances = _dbContext.Users
      .Where(u => u.Id == currentUserId)
      .Include(u => u.Balances)
      .ThenInclude(b => b.Currency)
      .ToList();
  

  改造后完全去掉对Currency的关联Include：

  // 新写法：仅查询业务表本身，不关联静态引用表
  var userBalances = _dbContext.Users
      .Where(u => u.Id == currentUserId)
      .Include(u => u.Balances)
      .ToList();
  

  因为第二步已经把所有Currency实体挂载到当前上下文的跟踪器中，EF Core的内置关系修复机制会自动根据Balance.CurrencyId外键，匹配对应的Currency实体并填充导航属性，既不需要手动赋值，也不会额外生成查询Currency的SQL。

方案核心优势 #

• 缓存复用率拉满：静态引用表的全量数据仅在Redis中存一份，不管是1000个用户还是10万个用户发起余额查询，都不会重复对Currency表执行查库操作，也不会因为每个用户的查询结果重复存储相同的Currency数据浪费Redis内存。
• 彻底规避变更跟踪异常：所有引用表实体都是通过显式Attach挂载的，状态明确为Unchanged，EF不会误将其识别为新增实体触发重复插入报错，也不需要手动给业务查询加AsNoTracking。
• 解决Join查询缓存复用率低的问题：之前带业务过滤条件的Join查询，SQL会因为不同用户的查询参数不同生成不同的缓存键，就算开了二级缓存，也只能每个用户单独存一份结果，缓存命中率极低，改造后从架构上就避免了这种无效缓存。
• 绕开EF一级缓存的局限性：EF内置的一级缓存仅在单个DbContext实例生命周期内有效，每个请求都是独立的上下文实例，本身就无法实现跨请求的复用，这套全局缓存机制直接突破了这个限制。

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