如何解决EF Core 3.1查询触发SQL聚集索引扫描的性能问题

• 现有Child表的非聚集索引不具备覆盖能力：当前IX_ChildEntities_ParentEntityID仅存储索引键ParentEntityID和聚集主键ID，查询所需的Value字段不在索引范围内，每匹配一行都要回表到聚集索引查找。当优化器预估匹配的子表行数超过阈值时，会判定全量扫描聚集索引+Bitmap过滤的成本远低于逐行回表的键查找成本，直接跳过现有非聚集索引，触发耗时数分钟的Clustered Index Scan。
• 执行计划漂移造成性能波动：Parent表按PlaceID+时间范围的查询，受统计信息精度、参数嗅探影响，优化器对窗口内父实体的行数预估偏差可达数倍到数十倍。预估行数低时走Index Seek路径（耗时2秒左右），预估行数高时误选Hash Join全扫路径（耗时4分钟左右），直接造成耗时大幅跳变。
• 系统提示缺索引的本质：sys.dm_db_missing_index_details检测到的缺失项不是ParentEntityID列本身的单列索引，是该索引缺失查询字段的包含属性。

1. 重构Child表索引为覆盖索引，消除回表成本 #

将原有的单列索引替换为包含查询字段的覆盖索引，让子表关联查询完全不需要访问聚集索引，从根本上杜绝Clustered Index Scan的触发可能。

• 数据库侧直接执行脚本：

-- 删除原单列索引
DROP INDEX IX_ChildEntities_ParentEntityID ON ChildEntities;
-- 创建覆盖索引，索引键保留ParentEntityID，包含查询需要的Value字段
CREATE NONCLUSTERED INDEX IX_ChildEntities_ParentEntityID_INCLUDE_Value 
ON ChildEntities (ParentEntityID ASC)
INCLUDE (Value)
WITH (ONLINE = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = ON);

• EF Core 3.1侧同步更新模型配置，避免后续迁移重建回旧索引结构：

modelBuilder.Entity<ChildEntity>()
    .HasIndex(c => c.ParentEntityID)
    .IncludeProperties(c => c.Value);

优化效果说明：该索引已包含查询所需的全部子表字段（ParentEntityID作为索引键、Value作为包含列、ID作为非聚集索引自动携带的聚集键），无论优化器预估匹配行数多少，都会直接选择该索引路径，不会再触发全表扫描，单这一项即可将关联环节的耗时稳定在百毫秒级。

2. 降低Parent表的预估偏差 #

针对Parent表的过滤索引优化统计信息更新机制，避免因统计信息过旧导致的计划误判：

ALTER INDEX IX_ParentEntities_PlaceID_DateTime ON ParentEntities
SET (
    STATISTICS_INCREMENTAL = ON, 
    AUTO_UPDATE_STATISTICS_ASYNC = ON
);

优化效果说明：打开异步自动统计更新后，当索引上的数据变更超过阈值时，不会阻塞用户查询等待统计信息刷新，同时增量统计会大幅提升大表的统计更新精度，减少行数预估偏差。

3. 固定稳定执行计划，杜绝计划漂移 #

利用Azure SQL内置的Query Store功能，将之前观测到的“走Index Seek、耗时2秒以内”的查询计划强制固定，避免后续因为参数嗅探、统计信息波动切到全扫的坏计划。操作路径为：在SSMS中打开对应数据库的Query Store，找到目标查询的所有历史执行计划，选择耗时最低、无Clustered Index Scan的计划设置为强制计划即可。

4. 消除不必要的排序开销 #

当前EF生成的SQL带了ORDER BY [p].[ID], [c].[ID]排序逻辑，这部分对应之前执行计划中19%开销占比的Parallelism Repartition Streams步骤。如果业务没有强制要求返回结果的排序规则，可以移除该排序逻辑；如果确实需要排序，覆盖索引建立后，索引本身的物理顺序已经和排序要求对齐，不需要额外的内存排序开销。

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