# dotnet-linq-优化 .NET 应用程序的 LINQ 性能模式。涵盖“IQueryable”服务器端评估和“IEnumerable”客户端具体化之间的关键区别、EF Core 热路径的编译查询、延迟执行陷阱、LINQ 到对象分配模式和何时放弃手动循环，以及用于零分配处理的基于 Span 的替代方案。 **超出范围：** EF Core DbContext 生命周期、迁移、拦截器和连接弹性 - 请参阅 [技能：dotnet-efcore-patterns]。战略数据架构（存储库模式、读/写分割、N+1 治理）——请参阅 [技能：dotnet-efcore-architecture]。跨度和内存基础知识 - 请参阅 [技能：dotnet-performance-patterns]。微基准测试设置 - 请参阅 [技能：dotnet-benchmarkdotnet]。交叉引用：[skill:dotnet-efcore-patterns] 用于 EF Core 上下文和 DbContext 使用中的编译查询，[skill:dotnet-performance-patterns] 用于跨度/内存基础和 ArrayPool 模式，[skill:dotnet-benchmarkdotnet] 用于测量 LINQ 优化影响。 ** ** ## IQueryable 与 IEnumerable 物化最有影响力的 LINQ 性能决策是评估发生的位置：在数据库服务器上 (`IQueryable`) 或在应用程序内存中 (`IEnumerable`)。 ### 问题 // 危险：将整个表具体化到内存中，然后在 C# 中进行过滤 IEnumerable 订单 = dbContext.Orders; var 最近 = orders.Where(o => o.CreatedAt > cutoff).ToList(); // SQL: SELECT * FROM Orders（没有 WHERE 子句！） // 正确：过滤器在数据库服务器上执行 IQueryable 订单 = dbContext.Orders; var 最近 = orders.Where(o => o.CreatedAt > cutoff).ToList(); // SQL: SELECT ... FROM 订单 WHERE CreatedAt > @cutoff ### 当物化发生时运营|效果 ---|--- `ToList()`、`ToArray()`、`ToDictionary()` |执行查询，将结果加载到内存中 `foreach` / `等待 foreach` |执行查询，流式传输结果 `AsEnumerable()` |从服务器评估切换到客户端评估 `Count()`、`Any()`、`First()`、`Single()` |执行查询，返回标量 `IQueryable` 上的 `Where()`、`Select()`、`OrderBy()`构建表达式树（不执行） `IEnumerable` 上的 `Where()`、`Select()`、`OrderBy()`延迟内存评估 ### 常见错误 // 错误 1：过滤之前的 AsEnumerable() var 结果 = dbContext.Orders .AsEnumerable() // <-- 切换到客户端评估 .Where(o => o.Total > 100) // 在内存中运行，而不是 SQL .ToList(); // 错误 2：在 IQueryable 谓词中调用 C# 方法 var 结果 = dbContext.Orders .Where(o => IsHighValue(o)) // 无法转换为 SQL；投掷或跌倒 .ToList(); // 修复：使用表达式兼容的谓词或物化后调用 var 结果 = dbContext.Orders .Where(o => o.Total > 100) // SQL 可翻译 .AsEnumerable() .Where(o => IsHighValue(o)) // 物化后的 C# 逻辑 .ToList(); // 错误 3：投影太多列 var name = dbContext.Orders.ToList().Select(o => o.CustomerName); // 加载所有列，然后在内存中选择一列 // 修复：实现之前的项目 var 名称 = dbContext.Orders.Select(o => o.CustomerName).ToList(); // SQL: 从订单中选择客户名称 ### 检测清单 * 在“Where”/“Select”之前任何“AsEnumerable()”或强制转换为“IEnumerable”都是潜在的服务器绕过 * EF Core 在回退到客户端评估时将“Microsoft.EntityFrameworkCore.Query”记录为警告级别 * 在开发期间启用 `ConfigureWarnings(w => w.Throw(RelationalEventId.MultipleCollectionIncludeWarning))` ** ** ## EF Core 热路径的编译查询编译查询消除了每次调用表达式树编译开销。对于每秒执行数千次的查询，这可以显着减少开销。 ### 标准编译查询公共密封类 OrderRepository(AppDbContext db) { // 编译一次，在所有调用中重复使用私有静态只读 Func> s_findById = EF.CompileAsyncQuery( （AppDbContext ctx，Guid id）=> ctx.Orders.FirstOrDefault(o => o.Id == id)); 私有静态只读 Func> s_findRecent = EF.CompileAsyncQuery( （AppDbContext ctx，日期时间截止）=> ctx.订单 .Where(o => o.CreatedAt > 截止) .OrderByDescending(o => o.CreatedAt)); 公共任务 <订单？> FindByIdAsync(Guid id) => s_findById(db, id); 公共 IAsyncEnumerable FindRecentAsync(DateTime cutoff) => s_findRecent(db, 截止); } ### 何时使用编译查询场景|使用编译查询？ ---|--- 高频查找（身份验证、缓存）|是的管理仪表板查询（低频）|否——开销可以忽略不计带有动态谓词的查询（用户搜索）|否——无法参数化形状使用不同的 `Include()` 进行查询 |否 - 包括更改表达式树形状 ### 限制 * 已编译查询不能使用动态 `Include()` 或条件 `Where()` 子句来更改表达式树形状 * 参数必须是简单类型（没有复杂的对象或集合） * `EF.CompileAsyncQuery` 对于单个结果返回 `Task`，对于集合返回 `IAsyncEnumerable` ** ** ## 延迟执行的陷阱 LINQ 使用延迟执行：查询运算符构建一个管道，仅在使用结果时才执行。这很强大，但会产生微妙的错误。 ### 多重枚举 // BUG: 枚举数据库查询两次 IQueryable query = dbContext.Orders.Where(o => o.Status == Status.Active); var count = query.Count(); // 执行 SQL（第一个查询） var items = query.ToList(); // 再次执行SQL（第二次查询） // 修复：实现一次 var items = dbContext.Orders .Where(o => o.Status == Status.Active) .ToList(); var count = items.Count; // 内存中，无 SQL ### 循环中的闭包捕获 // BUG：所有查询通过引用捕获相同的循环变量“i” var requests = new List>(); for (int i = 0; i < statuses.Length; i++) { querys.Add(dbContext.Orders.Where(o => o.Status == statuses[i])); // 'i' 通过引用捕获——所有查询都使用 i 的最终值 } // 修复：复制到循环体内的局部变量 for (int i = 0; i < statuses.Length; i++) { var localStatus = statuses[i]; querys.Add(dbContext.Orders.Where(o => o.Status == localStatus)); } 注意：C# 5+ `foreach` 循环变量的作用域是每次迭代，不会出现此错误。 “for”循环索引变量在迭代之间共享，这使得这是在循环中构建延迟 LINQ 查询时的常见陷阱。 ### 方法返回中的延迟执行 // 危险：返回未计算的查询——调用者可能没有意识到 // DbContext 可以在枚举之前释放公共 IEnumerable GetActiveOrders() { return dbContext.Orders.Where(o => o.Status == Status.Active); // 尚未评估 - 当调用者迭代时 DbContext 可能会被释放 } // 安全：返回之前实现公共异步任务> GetActiveOrdersAsync(CancellationToken ct) { 返回等待 dbContext.Orders .Where(o => o.Status == Status.Active) .ToListAsync(ct); } ** ** ## LINQ 到对象分配模式内存集合上的 LINQ 运算符分配迭代器、委托和中间集合。对于每秒处理数千个项目的热路径，这些分配可能会导致 GC 压力。 ### 分配来源运营|分配 ---|--- `Where()`、`Select()` |迭代器对象+委托 `ToList()`、`ToArray()` |新系列+可能调整大小 `OrderBy()` |完整副本用于排序 `GroupBy()` |字典+对象分组 `SelectMany()` |迭代器+内部迭代器局部变量的 Lambda 捕获 |每个捕获范围的闭包对象 ### 当 LINQ 分配很重要时对于大多数代码来说，LINQ 分配可以忽略不计。仅在以下情况下进行优化： * 处理在热路径上（每秒调用数千次） * BenchmarkDotNet 显示重要的“已分配”字节 * GC 指标（Gen0 收集/秒）表示压力 ### 手动循环替代方案 // LINQ：分配迭代器 + 委托 + List var 结果 = 项目 .Where(x => x.IsActive) .Select(x => x.名称) .ToList(); // 手动循环：单个 List 分配，无迭代器/委托开销 var result = new List(items.Count); foreach（项目中的变量项目） { if (项目.IsActive) { 结果.添加(项目.名称); } } // LINQ：分配迭代器 + 委托 + 布尔装箱（任意） var hasActive = items.Any(x => x.IsActive); // 手动循环：枚举器之外的零分配 var hasActive = false; foreach（项目中的变量项目） { if (项目.IsActive) { 有活动 = true; 休息; } } ### 减少分配而不放弃 LINQ 在进行手动循环之前，请考虑以下中间步骤： // 1. 对数组使用 Array.Find / Array.Exists（无迭代器分配） var first = Array.Find(items, x => x.IsActive); var 存在 = Array.Exists(items, x => x.IsActive); // 2. 当计数已知时预先确定集合的大小 var result = new List(items.Length); 结果.AddRange(items.Where(x => x.IsActive).Select(x => x.Name)); // 3. 使用静态 lambda 避免委托分配 (C# 9+) var result = items.Where(static x => x.IsActive).ToList(); // 注意：静态 lambda 可以防止意外的闭包捕获 // 但是委托已经被编译器缓存了 // 非捕获 lambda 表达式；主要好处是强制执行 ** ** ## 基于跨度的集合处理替代方案对于最高性能的场景，“Span”和“ReadOnlySpan”支持基于堆栈的零分配处理。这些 API 不兼容 LINQ，但涵盖常见模式。 ### 跨度搜索和过滤 // 零分配包含对数组的检查 ReadOnlySpan 值 = stackalloc int[] { 1, 2, 3, 4, 5 }; bool 发现 = value.Contains(3); // 零分配索引搜索 int索引=values.IndexOf(4); ### 用于字符串处理的内存扩展 // 零分配拆分和迭代 ReadOnlySpan csv = "爱丽丝,鲍勃,查理"; foreach（csv.Split(',') 中的 var 段） { ReadOnlySpan<字符> 值 = csv[段]; // 处理每个值而不分配字符串 } // 零分配修剪和比较 ReadOnlySpan 输入 =“你好”; bool match = input.Trim().SequenceEqual("hello"); ### 何时在 LINQ 上使用 Span 场景|方法 ---|--- 在紧密循环中解析 CSV/日志行 | `ReadOnlySpan` \+ `分割` 搜索排序数组 | `Span.BinarySearch` 处理来自 I/O 的字节缓冲区 | `ReadOnlySpan` 切片集合上的一般业务逻辑 | LINQ（微优化的可读性）有关全面的 Span/Memory 模式和 ArrayPool 使用情况，请参阅 [skill:dotnet-performance-patterns]。 ** ** ## 查询优化模式 ### 物化前的投影始终仅选择您需要的列： // 不好：加载整个实体图 var 订单 = 等待 dbContext.Orders .include(o => o.Lines) .include(o => o.Customer) .ToListAsync(ct); var 摘要 = 订单.Select(o => 新 { o.Id， o.客户.姓名，总计 = o.Lines.Sum(l => l.价格 * l.数量) }); // 好：查询中的项目——带有计算列的单个 SQL var 摘要 = 等待 dbContext.Orders .Select(o => 新 { o.Id，客户名称 = o.客户.名称, 总计 = o.Lines.Sum(l => l.价格 * l.数量) }) .ToListAsync(ct); ### 使用键集（Seek）方法进行分页 // 偏移分页：O(N) -- 服务器必须跳过行 var page = 等待 dbContext.Orders .OrderBy(o => o.Id) .Skip(页面大小 * 页数) .Take(页面大小) .ToListAsync(ct); // 键集分页：O(1) -- 索引查找 var page = 等待 dbContext.Orders .Where(o => o.Id > lastSeenId) .OrderBy(o => o.Id) .Take(页面大小) .ToListAsync(ct); ### 批量操作 // 错误：N 个 UPDATE 语句（每个跟踪实体更改一个） foreach（var order in order） { order.Status = OrderStatus.Archived; } 等待 dbContext.SaveChangesAsync(ct); // 在单次往返中生成 N 个单独的 UPDATE 语句 // 好：EF Core 7+ ExecuteUpdateAsync（单个 SQL 语句）等待 dbContext.Orders .Where(o => o.CreatedAt < 截止) .ExecuteUpdateAsync( s => s.SetProperty(o => o.Status, OrderStatus.Archived), CT）； ** ** ## 代理陷阱 1. **在过滤之前不要将 IQueryable 转换为 IEnumerable** \--这会默默地从服务器端 SQL 评估切换到客户端内存评估，可能会加载整个表。检查“AsEnumerable()”、显式转换或接受“IEnumerable”的方法签名。 2. **不要从存储库方法返回 IQueryable** \--调用者可以编写其他运算符，但 DbContext 可能会在枚举之前被释放。返回物化集合 (List) 或使用 IAsyncEnumerable。 3. **不要在没有基准的情况下优化 LINQ 分配** \-- LINQ 迭代器开销对于大多数业务逻辑来说可以忽略不计。在用手动循环替换 LINQ 之前，使用 [skill:dotnet-benchmarkdotnet] `[MemoryDiagnoser]` 来证明分配的重要性。 4. **不要将编译查询与动态谓词一起使用** \--编译查询缓存表达式树形状。如果每次调用查询形状发生变化（条件包含、动态过滤器），则编译后的查询会抛出或产生错误的结果。 5. **不要多次枚举延迟查询** \--每次枚举都重新执行底层源（数据库查询、网络调用）。当结果将被多次使用时，使用“ToList()”实现。 6. **不要使用`Skip()`/`Take()`进行深度分页** \--数据库上的偏移分页是O(N)。使用键集（查找）分页，并在最后看到的键上使用“Where”子句，以实现一致的性能，无论页面深度如何。 ** ** ## 参考文献 * [EF Core 查询评估]() * [EF Core 编译查询]() * [EF Core高效查询]() * [LINQ 执行模型（延迟与立即）]() * [MemoryExtensions 类]() * [EF Core 执行更新和执行删除]() * [EF Core 中的键集分页]()

Dotnet Linq 优化

包含技能