为什么你的EF Core查询依然慢？可能是缺少这1个包含列配置

第一章：为什么你的EF Core查询依然慢？可能是缺少这1个包含列配置

在使用 Entity Framework Core 进行数据访问时，开发者常常关注索引优化和查询语句结构，却忽略了数据库层面一个关键性能优化点——包含列（Included Columns）的配置。当查询涉及大量非键列时，即使主键已建立索引，数据库仍可能执行键查找（Key Lookup）操作，从而导致性能下降。

什么是包含列？

包含列是 SQL Server 中索引的一种优化机制，允许将非索引列附加到索引的叶级别，从而覆盖更多查询所需字段，避免回表操作。EF Core 本身不直接暴露“包含列”语法，但可通过 `IndexAttribute` 或 Fluent API 配合原生方法实现。

如何在EF Core中配置包含列

使用 Fluent API 在 `OnModelCreating` 方法中添加包含列配置：

// 配置索引并指定包含列
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Order>()
        .HasIndex(e => e.Status)
        .IncludeProperties(e => new { e.CreatedDate, e.CustomerName });
}

上述代码为 `Order` 实体的 `Status` 字段创建索引，并将 `CreatedDate` 和 `CustomerName` 作为包含列嵌入索引页中，使以下查询无需访问数据页即可完成：

• 减少 I/O 操作：查询仅需读取索引页即可获取全部所需数据
• 避免键查找：消除由非聚集索引导致的额外书签查找
• 提升查询吞吐：尤其适用于只读或报表类场景

配置方式	是否支持包含列	说明
IndexAttribute	否	无法定义包含列，仅支持索引键
Fluent API + IncludeProperties	是	需确保目标数据库为 SQL Server

第二章：深入理解EF Core中的索引与包含列

2.1 索引基础回顾：聚集索引与非聚集索引的区别

在数据库系统中，索引是提升查询性能的核心机制。其中，聚集索引和非聚集索引在数据存储结构上存在本质差异。

聚集索引（Clustered Index）

聚集索引决定了表中数据的物理存储顺序。每个表只能有一个聚集索引，因为数据行本身只能按一种方式排序。例如，在 SQL Server 中创建主键时，默认会生成聚集索引：

CREATE TABLE Users (
    UserID INT PRIMARY KEY,
    Name NVARCHAR(50)
);

上述语句中，UserID 成为聚集索引键，数据行将按照 UserID 的值物理排序存储。查询基于该字段时效率极高，因无需额外查找数据页。

非聚集索引（Non-Clustered Index）

非聚集索引独立于数据行存储，包含索引键值和指向实际数据的指针。一个表可拥有多个非聚集索引。

• 索引结构为B+树，叶子节点保存键值与行定位器（如聚集索引键或RID）
• 适用于频繁查询但不常更新的列

对比二者的关键特性可用下表说明：

特性	聚集索引	非聚集索引
数据存储	数据行按索引排序	独立结构，指向数据
数量限制	每表仅一个	可多个

2.2 什么是包含列（Included Columns）及其作用机制

包含列的定义

包含列是索引中非键列的集合，用于提升查询性能而不增加索引键的大小。它们不参与索引排序，但存储在索引的叶级别，使查询无需回表即可获取所需数据。

作用机制与优势

通过将常用但不用于搜索条件的列作为包含列添加到非聚集索引中，可实现覆盖索引的效果。例如：

CREATE NONCLUSTERED INDEX IX_Orders_CustomerId 
ON Orders (CustomerId) 
INCLUDE (OrderDate, TotalAmount);

上述语句创建了一个以 `CustomerId` 为键列、`OrderDate` 和 `TotalAmount` 为包含列的索引。当查询同时选择这三个字段时，数据库引擎可直接从索引叶节点获取全部数据，避免了对基表的额外访问。

• 减少I/O开销：避免书签查找（Bookmark Lookup）
• 突破索引键列限制：最多可包含1000列（受页大小约束）
• 提高执行效率：尤其适用于宽表和高频查询场景

2.3 包含列如何避免键查找提升查询性能

在执行查询时，若非聚集索引无法覆盖所有查询字段，SQL Server 会通过键查找从聚集索引中获取缺失数据，这将显著增加 I/O 开销。使用包含列（Included Columns）可扩展非聚集索引的覆盖能力，从而避免额外的键查找操作。

包含列的定义语法

CREATE NONCLUSTERED INDEX IX_Orders_CustomerId
ON Orders (CustomerId)
INCLUDE (OrderDate, TotalAmount);

上述语句在 `CustomerId` 上创建非聚集索引，并将 `OrderDate` 和 `TotalAmount` 作为包含列存储在叶级别。这些列不参与索引键排序，但随索引一并保存，使查询无需回表。

性能提升机制

当查询仅涉及索引键列与包含列时，执行计划将使用“索引扫描”或“索引查找”而不再触发“键查找”，减少逻辑读取次数。例如：

• 原需 1000 次逻辑读（含键查找）
• 添加包含列后降至 3 次逻辑读（仅索引访问）

合理使用包含列能有效实现索引覆盖，显著提升查询效率。

2.4 EF Core中定义包含列的API语法详解

在EF Core中，实体类的属性映射到数据库表的列是通过Fluent API或数据注解实现的。使用Fluent API可以更灵活地配置列的特性。

Fluent API中的列配置

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Product>()
        .Property(p => p.Name)
        .HasColumnName("ProductName")
        .HasColumnType("nvarchar(100)")
        .IsRequired();
}

上述代码将`Name`属性映射为名为`ProductName`的列，类型设为`nvarchar(100)`，并标记为非空。`HasColumnName`指定列名，`HasColumnType`定义数据库类型，`IsRequired`设置是否可为空。

常用列配置方法汇总

• HasColumnName：自定义列名称
• HasColumnType：指定底层数据库类型
• IsRequired：控制字段是否允许NULL
• HasMaxLength：设置字符串最大长度

2.5 实际案例对比：有无包含列的执行计划分析

在SQL查询优化中，包含列（Included Columns）能显著影响执行计划。通过实际案例对比可清晰观察其差异。

测试场景设定

假设存在订单表 `Orders`，索引建立在 `CustomerID` 上，是否包含 `OrderDate` 作为包含列进行对比。

-- 不含包含列的索引
CREATE INDEX IX_Orders_Customer ON Orders(CustomerID);

-- 含包含列的索引
CREATE INDEX IX_Orders_Customer_Inc ON Orders(CustomerID) INCLUDE (OrderDate);

上述代码中，第二个索引将 `OrderDate` 存储在叶级别，不参与B树排序，但可避免键查找。

执行计划对比

当执行以下查询时：

SELECT CustomerID, OrderDate 
FROM Orders 
WHERE CustomerID = 'CUST001';

使用包含列索引时，执行计划为“索引扫描 + 覆盖索引”，而无包含列则触发“键查找”，增加IO开销。

索引类型	逻辑读取次数	执行操作
无包含列	15	Index Seek + Key Lookup
有包含列	4	Index Seek (Covered)

第三章：性能瓶颈诊断与场景识别

3.1 如何通过SQL Server Profiler识别键查找问题

在性能调优过程中，频繁的键查找（Key Lookup）会显著影响查询效率。使用 SQL Server Profiler 可以直观捕获此类操作。

启动跟踪并筛选关键事件

在 Profiler 中新建跟踪，选择 **Tuning** 模板，并添加以下事件：

• RPC:Completed
• SQL:BatchCompleted
• Showplan XML

其中，Showplan XML 能记录执行计划，便于发现键查找操作。

分析执行计划中的键查找

当查询涉及非聚集索引但需回表获取数据时，执行计划中会出现 `` 或 `` 节点。例如：

<IndexScan Lookup='true' ...>
  <Object Table='[Orders]' Index='IX_Orders_OrderDate'/>
</IndexScan>

该代码片段表明，系统通过非聚集索引定位数据后，回表读取聚簇索引以获取完整行数据，即发生键查找。

优化建议

可通过覆盖索引或包含列减少键查找。例如：

CREATE NONCLUSTERED INDEX IX_Orders_OrderDate 
ON Orders (OrderDate) INCLUDE (CustomerID, TotalAmount);

此索引将常用字段包含在内，避免回表操作，从而提升查询性能。

3.2 使用EF Core日志输出洞察生成的SQL语句

在开发和调试基于Entity Framework Core的应用程序时，了解EF Core生成的实际SQL语句至关重要。通过启用日志记录，可以捕获上下文执行的数据库操作。

配置日志记录

在`DbContext`配置中，使用`EnableSensitiveDataLogging`和`LogTo`方法可输出SQL语句：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .EnableSensitiveDataLogging()
        .LogTo(Console.WriteLine, new[] { DbLoggerCategory.Database.Command.Name });
}

上述代码将所有数据库命令日志输出到控制台。`DbLoggerCategory.Database.Command.Name`确保仅捕获SQL执行相关的日志，避免冗余信息。

日志输出内容

每条日志包含完整的SQL语句、参数值及其类型。例如：

• SQL文本：如 SELECT * FROM Users WHERE Id = @p0
• 参数绑定：显示 @p0 = 1 (Nullable<Int32>)
• 执行时间：可结合日志时间戳分析性能

此机制有助于识别N+1查询、未预期的全表扫描等性能问题，是优化数据访问层的关键手段。

3.3 典型慢查询场景模拟与包含列优化验证

慢查询场景构建

在高并发环境下，用户订单表 orders 的查询响应时间显著上升。典型SQL如下：

SELECT order_id, user_name, total_amount 
FROM orders 
WHERE create_time > '2023-01-01' AND status = 'completed';

该语句在未优化时需回表查询，导致大量随机I/O。

包含列优化实施

通过添加包含列索引，将非键字段预加载至索引页中：

CREATE INDEX idx_orders_ctime_status 
ON orders(create_time, status) 
INCLUDE (user_name, total_amount);

此索引使查询完全覆盖，避免回表操作，显著降低逻辑读取次数。

性能对比分析

指标	优化前	优化后
逻辑读取（次）	12,450	890
响应时间（ms）	342	18

第四章：在EF Core项目中正确配置包含列

4.1 在OnModelCreating中添加包含列的完整示例

在 Entity Framework Core 中，`OnModelCreating` 方法是配置模型的核心入口。通过此方法，可以精确控制实体与数据库表之间的映射关系，包括使用包含列（Included Columns）优化查询性能。

配置包含列的场景

当使用覆盖索引时，数据库可避免回表查询。在 EF Core 中可通过 `HasIndex` 配合 `IncludeProperties` 实现。

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Product>()
        .HasIndex(p => p.CategoryId)
        .IncludeProperties(p => new { p.Name, p.Price });
}

上述代码为 `Product` 实体的 `CategoryId` 字段创建索引，并将 `Name` 和 `Price` 作为包含列加入索引页中。这意味着仅需扫描索引即可满足相关查询，显著提升性能。

支持的数据存储

• SQL Server：完全支持包含列
• SQLite、PostgreSQL：不支持该特性，配置将被忽略

合理利用此功能可在高并发读取场景下降低 I/O 开销。

4.2 迁移文件生成与SQL脚本的审查技巧

在数据库变更管理中，迁移文件的生成是保障数据一致性的关键步骤。通过框架提供的CLI工具可自动生成基础SQL脚本，例如使用命令：

php artisan make:migration add_email_to_users --table=users

该命令将创建一个包含up()和down()方法的PHP类，用于定义正向与回滚操作。生成后需重点审查输出的SQL语句是否符合索引规范、字段类型一致性及外键约束。

SQL审查要点清单

• 避免使用TEXT存储短字符串，应选用VARCHAR并设定合理长度
• 新增外键必须显式命名，并确保引用表存在对应索引
• 修改字段时注意默认值对已有数据的影响

结合自动化工具与人工走查，能有效降低生产环境数据库变更风险。

4.3 多字段组合场景下的包含列设计策略

在处理多字段查询条件时，合理使用包含列（Included Columns）能显著提升索引覆盖能力，避免回表操作。通过将高频查询字段作为包含列添加至非聚集索引中，可实现性能优化。

索引设计示例

CREATE NONCLUSTERED INDEX IX_Orders_CustomerDate
ON Orders (CustomerId, OrderDate)
INCLUDE (TotalAmount, Status);

该索引以 `CustomerId` 和 `OrderDate` 为键列，支持按客户和时间范围的查询；而 `TotalAmount` 与 `Status` 作为包含列，使查询无需访问主表即可返回完整结果。

适用场景分析

• 查询频繁使用多个 WHERE 条件组合
• SELECT 列表中存在非键字段但需避免书签查找
• 写入性能可接受小幅下降以换取读取加速

合理规划包含列，可在复杂查询中减少 I/O 开销，提升执行效率。

4.4 避免过度使用包含列带来的维护与存储代价

在设计索引时，包含列（Included Columns）虽能提升查询性能，但滥用将引发显著的存储开销与维护成本。

包含列的潜在代价

每个包含列都会增加索引页的大小，导致更多磁盘I/O和内存占用。尤其在宽表场景下，数据冗余可能成倍放大。

• 增加的存储空间：每行数据复制包含列到非聚集索引中
• 更高的维护成本：INSERT/UPDATE/DELETE需同步更新多个索引结构
• 统计信息膨胀：优化器统计信息更复杂，影响执行计划稳定性

优化建议与代码示例

-- 不推荐：过度添加包含列
CREATE NONCLUSTERED INDEX IX_Orders_Bad 
ON Orders (CustomerId) 
INCLUDE (ProductName, CategoryName, UnitPrice, OrderDate, Status);

-- 推荐：仅包含必要字段
CREATE NONCLUSTERED INDEX IX_Orders_Good 
ON Orders (CustomerId) 
INCLUDE (OrderDate, Status);

上述优化减少了约60%的索引体积，同时保持关键查询性能。应定期审查索引使用率，移除低效包含列以降低系统负担。

第五章：结语：让EF Core查询真正高效起来

理解查询执行计划

数据库查询性能瓶颈往往源于未优化的执行计划。使用 SQL Server 的 SET STATISTICS IO ON 可分析 EF Core 生成的 SQL 对数据页的读取情况。例如，一个未加索引的 Where(p => p.Name.Contains("test")) 查询可能导致全表扫描。

• 始终在关键字段上创建索引，尤其是外键和常用筛选字段
• 利用 AsNoTracking() 提升只读查询性能
• 避免在循环中执行查询，应批量加载相关数据

合理使用 Include 与投影

过度使用 Include 易导致“笛卡尔爆炸”。例如，查询订单及其明细时，若同时包含客户信息且数据量大，应考虑拆分查询或使用 DTO 投影减少负载。

var orders = context.Orders
    .Where(o => o.CreatedDate >= DateTime.Today.AddDays(-7))
    .Select(o => new OrderSummaryDto
    {
        Id = o.Id,
        CustomerName = o.Customer.Name,
        TotalItems = o.OrderItems.Sum(oi => oi.Quantity)
    })
    .ToList();

监控与持续优化

部署 MiniProfiler 或使用 EF Core 的 LogTo 方法记录慢查询。建立基线指标，如平均响应时间低于 100ms，逻辑读取页数少于 50。

优化手段	适用场景	预期收益
索引优化	高频筛选字段	减少 I/O 30%-70%
AsNoTracking	报表查询	CPU 下降 20%-40%