非持久化内存优化表能否可靠用作.NET/EF Core缓存？

我们使用EF Core搭配SQL Server作为数据库上下文，同时将部分外部数据源缓存于IDictionary等内存对象中，并通过OData对外提供Web服务。理想状态下，EF Core查询与OData映射、查询、展开等操作可统一视为单一数据源/EF Core提供程序/数据库上下文，无需手动合并数据以简化开发。

考虑到缓存数据含敏感信息，我们不愿将其存入常规表或持久化内存优化表（避免数据静态存储于数据库、备份中），因此考虑采用SQL Server非持久化内存优化表作为缓存，探讨其可靠性。

我们提出了一个理论方案，基于三点假设：

1. 非持久化内存优化表仅在SQL Server重启时重置；
2. 所有非持久化内存优化表会同步重置，不存在单表重置情况；
3. SQL Server重启耗时较长，无需频繁检查。

该方案通过后台进程每隔x秒查询虚拟内存优化表SELECT COUNT(value) FROM DUMMY：

• 若出现异常（重试后）则将Web服务设为错误状态；
• 若计数为0则判定服务器重启，进入初始化状态，填充所有内存优化表后向DUMMY表添加值并退出初始化；
• 若计数为1则正常运行。

现针对该方案提出具体问题：

1. 上述假设（主要为1、2）是否成立？
2. 是否有基于SQL Server事件的替代方案？
3. EF Core中是否有简便方法暂停除工作进程外的所有查询？
4. 是否有更优的整体解决方案？

1. 假设1、2是否成立？ #

• 假设1：基本成立，但存在边界情况。非持久化内存优化表（指定DURABILITY=SCHEMA_ONLY）的数据仅存于SQL Server实例的内存中，正常重启实例、服务器断电、故障转移（如Always On）都会清空数据。极端情况下，实例因内存不足强制回收内存优化表资源（概率极低，内存优化表优先级远高于普通缓存）也会导致数据丢失，但常规场景下可认为只有实例重启会触发重置。
• 假设2：完全成立。所有非持久化内存优化表的生命周期与SQL Server实例绑定，实例关闭时会统一释放所有内存池资源，不存在单表单独重置的可能。

2. 基于SQL Server事件的替代方案？ #

有两种可靠的事件驱动方案替代定时轮询：

• 扩展事件（Extended Events）：监听sqlserver.instance_started事件，该事件在SQL Server实例启动完成后触发。可通过Microsoft.SqlServer.XEvent.Linq库在应用端订阅事件，一旦收到触发信号，直接启动缓存初始化流程，无需定时轮询。
• 服务器启动触发器：创建服务器级STARTUP触发器，实例启动时自动执行存储过程，例如向一个专用的持久化小表写入启动标记（非持久化表启动时为空，无法存标记）。应用端可通过EF Core监听该标记表的变化，触发初始化逻辑。注意触发器需控制执行时长，避免影响实例启动。

3. EF Core中是否有简便方法暂停除工作进程外的所有查询？ #

可通过以下三种方式实现：

• 全局查询过滤器+状态开关：在DbContext中定义全局布尔变量（如IsMaintenanceMode），给所有实体添加查询过滤器：

  modelBuilder.Entity<YourEntity>().HasQueryFilter(e => !IsMaintenanceMode || IsWorkerProcess);
  

  其中IsWorkerProcess可通过注入的专属配置或请求头（如X-Worker-Process）识别，仅工作进程能绕过过滤器。
• ASP.NET Core中间件拦截：在中间件中检查服务状态，若处于初始化/维护状态，除工作进程请求（通过请求标识识别）外，直接返回503 Service Unavailable，拦截所有进入EF Core的查询。
• DbContext包装器：自定义DbContext包装类，在执行查询前检查服务状态，非工作进程的查询直接抛出异常或返回空结果，仅工作进程可正常执行。

4. 更优的整体解决方案？ #

推荐两种更可靠的方案，避免依赖SQL Server内存表的局限性：

方案一：应用级内存缓存+EF Core视图合并 #

• 将敏感缓存数据存储在应用进程内存（如IMemoryCache）或分布式内存缓存（多实例部署时），在EF Core中创建数据库视图，通过自定义DbFunction将SQL Server持久化数据与内存缓存数据合并，OData直接映射该视图，实现单一数据源体验。
• 优点：敏感数据完全不落地，无需依赖SQL Server内存表；EF Core与OData映射逻辑统一，开发复杂度低。
• 注意：多实例部署需用分布式缓存或事件总线同步缓存更新。

方案二：SQL Server全局临时表+EF Core动态模型 #

• 使用SQL Server全局临时表（##TempTable）存储敏感缓存数据，全局临时表仅在创建它的会话关闭后删除，可通过后台常驻会话保持存活。EF Core动态注册临时表的实体模型，实现与持久化表一致的查询体验。
• 优点：敏感数据不会被备份，SQL Server重启后自动清空；EF Core可直接映射，OData支持良好。
• 注意：需保持永久会话维护临时表，避免被自动删除；多实例应用需处理并发创建临时表的冲突。

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