
# 结论先行

EF Core 的性能差距不在 ORM 本身，而在**你怎么用它**。同一台机器、同一个 10,000 行的 SQLite 表，实测四个数字：

| 场景 | 慢的写法 | 快的写法 | 差距 |
|---|---|---|---|
| 全表查询 1 万行 | 跟踪查询 23.7ms / 8291KB | `AsNoTracking` 8.5ms / 3388KB | 2.8 倍，内存省 59% |
| 主键点查 2 万次 | 普通 LINQ 32.5μs/次 | 编译查询 6.9μs/次 | 4.7 倍 |
| 插入 1000 行 | 逐行 `SaveChanges` 346ms | `AddRange` + 一次 `SaveChanges` 21ms | 16.5 倍 |
| 批量改 1000 行 | 加载实体 + `SaveChanges` 24ms | `ExecuteUpdate` 6ms | 4 倍 |

两个静默坑：**逐行 SaveChanges 等于每行开一个事务**；**ExecuteUpdate 之后，变更追踪器里的旧数据还在，`Find()` 会把脏值还给你**。下面全是实测过程和复现步骤。

# 测试环境

- .NET SDK 10.0.201，runtime 10.0.5，EF Core 10.0.5
- Apple M4，macOS 26.7.1（arm64）
- SQLite（内存模式 `Data Source=:memory:`），默认配置，未调任何 EF 开关
- 每项测 5 轮取中位数，前 3 轮预热；分配量用 `GC.GetAllocatedBytesForCurrentThread()` 测

复现步骤：建一个 `net10.0` 控制台项目，引用 `Microsoft.EntityFrameworkCore.Sqlite` 10.0.5，跑完看输出。完整代码在文末。

```xml
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <Optimize>true</Optimize>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="10.0.5" />
  </ItemGroup>
</Project>
```

# 实测一：AsNoTracking，白捡的 2.8 倍

查询同一万行并物化成 `List<Product>`：

```csharp
var tracked = db.Products.Where(p => p.Stock >= 0).ToList();
var noTrack = db.Products.AsNoTracking().Where(p => p.Stock >= 0).ToList();
```

| 指标 | 跟踪查询 | AsNoTracking |
|---|---|---|
| 耗时（5 轮中位） | 23.7ms | 8.5ms |
| 托管堆分配 | 8291KB | 3388KB |
| ChangeTracker 条目 | 10000 | 0 |

慢在哪？跟踪查询要给每个实体做快照、建追踪条目。扫描结束后 `ChangeTracker.Entries().Count()` 是 **10000**，这些条目挂在内存里直到 `Clear()` 或 Context 释放。

两个要点：

1. **只读查询不加 AsNoTracking 是纯浪费**。速度差 2.8 倍，分配差 59%，都是白付的。
2. 跟踪查询的代价随结果集线性涨。分页查 20 行无所谓，全表导出、报表类查询差别就压不住了。

# 实测二：编译查询，4.7 倍不是玄学

同一个主键点查跑 2 万次：

```csharp
var compiled = EF.CompileQuery((AppDb c, int id) =>
    c.Products.AsNoTracking()
     .Where(p => p.Id == id)
     .Select(p => new { p.Id, p.Name, p.Stock })
     .FirstOrDefault());

// 6867~6950 ns/op
_sink = compiled(db, id);

// 29058~32494 ns/op
_sink = db.Products.AsNoTracking().Where(p => p.Id == id)
    .Select(p => new { p.Id, p.Name, p.Stock }).FirstOrDefault();
```

普通 LINQ 每次都要过一遍表达式树解析、SQL 生成。EF 有查询缓存，但**缓存命中的前提是表达式树完全一致**，比对本身也有成本。编译查询把这步提前到启动时做一次。

边界失效情形：编译查询**查询形状写死**。想加个 `Where` 条件、换个投影，就得再编译一个。所以它只适合热路径上的固定查询，不适合当通用优化。

# 实测三：逐行 SaveChanges，20 倍的学费

插入 1000 行，两种写法：

```csharp
// 慢：346~448ms，每行一个事务
for (int i = 0; i < 1000; i++)
{
    db.Products.Add(new Product { ... });
    db.SaveChanges();
}

// 快：19~21ms，一批一个事务
db.Products.AddRange(Enumerable.Range(0, 1000).Select(i => new Product { ... }));
db.SaveChanges();
```

两轮实测 16.5 倍和 23 倍。差距大头的来源不是循环开销，是**事务数**：每次 `SaveChanges` 自带一个事务提交，SQLite 内存库都要走一遍 begin/commit。1000 次提交对 1 次提交，怎么都是十几倍起步。

纠正一个误传：很多人以为 EF 插入慢，"一条一条 INSERT"。其实 `SaveChanges` 本来就自动批量生成多值 INSERT，真正的坑是**把 SaveChanges 放进循环里**。

# 实测四：ExecuteUpdate，4 倍还省内存

把 1000 行的 `Stock` 加 1：

```csharp
// 24ms：先加载 1000 个实体，改属性，SaveChanges 生成 1000 条 UPDATE
var rows = db.Products.Where(p => p.Name!.StartsWith("ins-batch")).ToList();
foreach (var r in rows) r.Stock += 1;
db.SaveChanges();

// 6ms：一条 UPDATE 直接落库
db.Products.Where(p => p.Name!.StartsWith("ins-single"))
   .ExecuteUpdate(s => s.SetProperty(p => p.Stock, p => p.Stock + 1));
```

`ExecuteUpdate` 在数据库端一条语句搞定，不物化实体、不进变更追踪器。EF Core 7 引入，用起来没有理由犹豫。

# 坑一：ExecuteUpdate 不经过 SaveChanges

实测在 DbContext 里覆写 `SaveChanges` 加计数器，跑完 `ExecuteUpdate` 后 **SaveChangesCalls = 0**。

后果：所有挂在 `SaveChanges` 上的东西全部失效——拦截器、审计日志、软删除过滤、`UpdatedAt` 时间戳注入。业务里靠这些机制保证数据一致性的，混用 `ExecuteUpdate` 就是静默绕过。

# 坑二：ExecuteUpdate 之后，ChangeTracker 在脏读

这是本次实测最值得记的坑。完整现场：

```csharp
var row = db.Products.First(p => p.Id == 1);      // 进了变更追踪器，Stock=1
db.Products.Where(p => p.Id == 1)
   .ExecuteUpdate(s => s.SetProperty(p => p.Stock, 999));  // 数据库已改成 999

var cached = db.Products.Find(1);                  // Stock=1 ← 脏值！
var fresh  = db.Products.AsNoTracking().First(p => p.Id == 1);  // Stock=999 ← 真值
```

实测输出：`tracked entity Stock=1，db actual Stock=999`。

原因：`Find()` 优先查变更追踪器缓存，**不回数据库**。`ExecuteUpdate` 绕过追踪器直接改库，缓存里的旧值没人通知。同一个 Context 里先跟踪、后 `ExecuteUpdate`、再 `Find`，拿到的是过期数据，而且没有任何报错。

防御姿势：`ExecuteUpdate` 之后立刻 `ChangeTracker.Clear()`，或者批量更新走独立的 Context 实例。

# 怎么选

| 场景 | 写法 |
|---|---|
| 只读查询 | 一律 `AsNoTracking`（或 `AsNoTrackingWithIdentityResolution`） |
| 热路径固定查询 | `EF.CompileQuery` |
| 循环里调 SaveChanges | 移出循环，`AddRange` + 一次提交 |
| 大批量改/删，不需要拦截器 | `ExecuteUpdate` / `ExecuteDelete`，之后 `Clear()` 追踪器 |
| 需要审计/拦截器/触发级联 | 老老实实走 `SaveChanges` |

数字是 M4 + 内存 SQLite 跑出来的，绝对值随机器变，倍率的量级不会。你的库、你的表，抄文末代码跑一遍才算数。

# 附：完整实测代码

```csharp
using System.Diagnostics;
using Microsoft.Data.Sqlite;
using Microsoft.EntityFrameworkCore;

Console.WriteLine($"runtime={Environment.Version}");
Console.WriteLine($"efcore={typeof(DbContext).Assembly.GetName().Version!.ToString(3)}");

object _sink = new();
var conn = new SqliteConnection("Data Source=:memory:");
conn.Open();
var opts = new DbContextOptionsBuilder<AppDb>().UseSqlite(conn).Options;
const int N = 10_000;

using (var db = new AppDb(opts))
{
    db.Database.EnsureCreated();
    db.Products.AddRange(Enumerable.Range(1, N).Select(i =>
        new Product { Name = $"product-{i}", Price = i % 100 + 0.5m, Stock = i % 50 }));
    db.SaveChanges();
    db.ChangeTracker.Clear();
}

// 1. 全表扫描：tracked vs AsNoTracking
using (var db = new AppDb(opts))
{
    for (int i = 0; i < 3; i++)
    {
        _sink = db.Products.Where(p => p.Stock >= 0).ToList();
        _sink = db.Products.AsNoTracking().Where(p => p.Stock >= 0).ToList();
        db.ChangeTracker.Clear();
    }
    for (int i = 0; i < 5; i++)
    {
        GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect();
        long a0 = GC.GetAllocatedBytesForCurrentThread();
        var sw = Stopwatch.StartNew();
        _sink = db.Products.Where(p => p.Stock >= 0).ToList();
        sw.Stop();
        Console.WriteLine($"tracked {sw.Elapsed.TotalMilliseconds:F1}ms " +
            $"{(GC.GetAllocatedBytesForCurrentThread() - a0) / 1024}KB");
        db.ChangeTracker.Clear();
        GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect();
        a0 = GC.GetAllocatedBytesForCurrentThread();
        sw = Stopwatch.StartNew();
        _sink = db.Products.AsNoTracking().Where(p => p.Stock >= 0).ToList();
        sw.Stop();
        Console.WriteLine($"notrack {sw.Elapsed.TotalMilliseconds:F1}ms " +
            $"{(GC.GetAllocatedBytesForCurrentThread() - a0) / 1024}KB");
        db.ChangeTracker.Clear();
    }
}

// 2. 编译查询 vs 普通 LINQ
using (var db = new AppDb(opts))
{
    var compiled = EF.CompileQuery((AppDb c, int id) =>
        c.Products.AsNoTracking().Where(p => p.Id == id)
         .Select(p => new { p.Id, p.Name, p.Stock }).FirstOrDefault());

    for (int i = 0; i < 2000; i++)
    {
        _sink = compiled(db, i % N + 1);
        _sink = db.Products.AsNoTracking().Where(p => p.Id == i % N + 1)
            .Select(p => new { p.Id, p.Name, p.Stock }).FirstOrDefault();
    }
    const int iter = 20_000;
    var sw = Stopwatch.StartNew();
    for (int i = 0; i < iter; i++) _sink = compiled(db, i % N + 1);
    Console.WriteLine($"compiled {sw.Elapsed.TotalMilliseconds / iter * 1000:F0}ns/op");
    sw = Stopwatch.StartNew();
    for (int i = 0; i < iter; i++)
        _sink = db.Products.AsNoTracking().Where(p => p.Id == i % N + 1)
            .Select(p => new { p.Id, p.Name, p.Stock }).FirstOrDefault();
    Console.WriteLine($"regular  {sw.Elapsed.TotalMilliseconds / iter * 1000:F0}ns/op");
}

// 3. 插入：逐行 SaveChanges vs AddRange 批量
using (var db = new AppDb(opts))
{
    var sw = Stopwatch.StartNew();
    for (int i = 0; i < 1000; i++)
    {
        db.Products.Add(new Product { Name = $"ins-single-{i}", Price = 1m, Stock = 1 });
        db.SaveChanges();
    }
    Console.WriteLine($"per-row SaveChanges {sw.Elapsed.TotalMilliseconds:F0}ms");
    db.ChangeTracker.Clear();
    sw = Stopwatch.StartNew();
    db.Products.AddRange(Enumerable.Range(0, 1000)
        .Select(i => new Product { Name = $"ins-batch-{i}", Price = 1m, Stock = 1 }));
    db.SaveChanges();
    Console.WriteLine($"AddRange+1xSaveChanges {sw.Elapsed.TotalMilliseconds:F0}ms");
    db.ChangeTracker.Clear();
}

// 4. 批量更新：tracked+SaveChanges vs ExecuteUpdate
using (var db = new AppDb(opts))
{
    var sw = Stopwatch.StartNew();
    var rows = db.Products.Where(p => p.Name!.StartsWith("ins-batch")).ToList();
    foreach (var r in rows) r.Stock += 1;
    db.SaveChanges();
    Console.WriteLine($"tracked+SaveChanges {sw.Elapsed.TotalMilliseconds:F0}ms");
    db.ChangeTracker.Clear();
    sw = Stopwatch.StartNew();
    db.Products.Where(p => p.Name!.StartsWith("ins-single"))
        .ExecuteUpdate(s => s.SetProperty(p => p.Stock, p => p.Stock + 1));
    Console.WriteLine($"ExecuteUpdate {sw.Elapsed.TotalMilliseconds:F0}ms");
}

// 5. 两个坑
using (var db = new AppDb(opts))
{
    var row = db.Products.First(p => p.Id == 1);
    db.Products.Where(p => p.Id == 1)
        .ExecuteUpdate(s => s.SetProperty(p => p.Stock, 999));
    Console.WriteLine($"Find (cached) = {db.Products.Find(1)!.Stock}");
    Console.WriteLine($"db actual     = {db.Products.AsNoTracking().First(p => p.Id == 1).Stock}");
    Console.WriteLine($"SaveChanges calls during ExecuteUpdate = {db.SaveChangesCalls}");
}

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = "";
    public decimal Price { get; set; }
    public int Stock { get; set; }
}

public class AppDb(DbContextOptions<AppDb> options) : DbContext(options)
{
    public DbSet<Product> Products => Set<Product>();
    public int SaveChangesCalls { get; private set; }
    public override int SaveChanges() { SaveChangesCalls++; return base.SaveChanges(); }
}
```

`dotnet run -c Release` 即可复现。


EF Core 的性能差距不在 ORM 本身，而在你怎么用它。同一台机器、同一个 10,000 行的 SQLite 表，实测四个数字：

EF Core 10 实测：AsNoTracking 快 2.8 倍，逐行 SaveChanges 慢 20 倍，ExecuteUpdate 有个静默脏读坑

数据库

后端

EF Core性能差异源于使用方式而非ORM本身：实测全表查询用AsNoTracking提速2.8倍且内存省59%；编译查询主键点查快4.7倍；AddRange批量插入比逐行SaveChanges快16.5倍；ExecuteUpdate批量更新快4倍。注意ExecuteUpdate绕过ChangeTracker，后续Find可能返回脏数据，需调用Clear()。

数据一致性

代码解释

SQLite

2026上云采购 | AI焕新·智启新局

tdata

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

EF Core性能差异源于使用方式而非ORM本身：实测全表查询用AsNoTracking提速2.8倍且内存省59%；编译查询主键点查快4.7倍；AddRange批量插入比逐行SaveChanges快16.5倍；ExecuteUpdate批量更新快4倍。注意ExecuteUpdate绕过ChangeTracker，后续F...

EF Core 10 实测：AsNoTracking 快 2.8 倍，逐行 SaveChanges 慢 20 倍，ExecuteUpdate 有个静默脏读坑-腾讯云开发者社区-腾讯云

EF Core 10 实测：AsNoTracking 快 2.8 倍，逐行 SaveChanges 慢 20 倍，ExecuteUpdate 有个静默脏读坑

EF Core 10 实测：AsNoTracking 快 2.8 倍，逐行 SaveChanges 慢 20 倍，ExecuteUpdate 有个静默脏读坑

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐