从 ChangeTracker 到 SQL Batch 的性能诊断与优化

问题背景

真实场景：订单系统在白天吞吐稳定，凌晨高峰出现周期性尖峰。接口平均耗时变化不大，但 P95 从 80ms 抬到 420ms，数据库 CPU 也出现波峰。

排查后发现：

• 应用层每次批量处理 2000 条数据
• 循环中频繁触发变更检测
• 每条数据都单独 SaveChanges
• 最终生成大量碎片化 SQL 往返

这类问题看起来像"数据库有点拉，扛不住了"，实际上很多成本来自应用侧写入链路组织不当。

原理解析

ChangeTracker 负责记录变更

EF Core 需要知道哪些实体是新增、修改、删除，这些状态都由 ChangeTracker 管理。默认情况下，EF Core 会在多个时机触发 DetectChanges，例如：

• 调用 SaveChanges / SaveChangesAsync
• 访问部分跟踪集合
• 某些 Add / Attach 组合场景

如果一个 DbContext 里挂了大量实体，频繁 DetectChanges 会带来明显 CPU 开销。

SaveChanges 并不是"一条语句"

一次 SaveChanges 大致会经历这些步骤：

1. 执行变更检测，确定实体状态
2. 生成修改命令（insert/update/delete）
3. 按提供程序规则组装批次（batch）
4. 开启事务并执行命令
5. 成功后调用 AcceptAllChanges

性能问题通常出在 2-4 步：命令太碎、批次太小、往返太多、事务范围不合理。

SQL Batch 决定数据库往返次数

以 SQL Server 为例，EF Core 会尽可能把多条 DML 合并到一个批次中执行，但合并能力受多种因素影响：

• 提供程序特性
• 参数数量上限
• 命令类型是否可并行拼接
• 配置的批次大小（MaxBatchSize）

如果批量导入被写成"每条一存"，数据库会收到大量短 SQL，吞吐会明显下降。

AcceptAllChanges 是可控的

默认 SaveChanges 成功后会立即 AcceptAllChanges，将实体状态重置为 Unchanged。在高频批处理场景，可以使用：

|---|--------------------------------------------------------------------|
| | await db.SaveChangesAsync(acceptAllChangesOnSuccess: false, ct); |
| | db.ChangeTracker.AcceptAllChanges(); |

这样可以把提交和状态确认拆开，给你更细粒度的异常处理空间。

示例代码

先定义一个简化实体：

|---|---------------------------------------------------|
| | public sealed class InventoryLog |
| | { |
| | public long Id { get; set; } |
| | public string Sku { get; set; } = string.Empty; |
| | public int Delta { get; set; } |
| | public DateTime CreatedAtUtc { get; set; } |
| | } |

DbContext 配置日志和批大小：

|---|-----------------------------------------------------------------------------------|
| | public sealed class AppDbContext : DbContext |
| | { |
| | public DbSet<InventoryLog> InventoryLogs => Set<InventoryLog>(); |
| | |
| | protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) |
| | { |
| | optionsBuilder |
| | .UseSqlServer( |
| | "Server=.;Database=DemoDb;Trusted_Connection=True;TrustServerCertificate=True", |
| | sql => sql.MaxBatchSize(128)) |
| | .EnableDetailedErrors() |
| | .LogTo(Console.WriteLine, LogLevel.Information); |
| | } |
| | } |

先看一个常见低效写法：

|---|------------------------------------------------------------------------------------------------------------------------|
| | public static async Task InsertLogsBadAsync(AppDbContext db, IReadOnlyList<InventoryLog> logs, CancellationToken ct) |
| | { |
| | foreach (var log in logs) |
| | { |
| | db.InventoryLogs.Add(log); |
| | await db.SaveChangesAsync(ct); |
| | } |
| | } |

问题很直接：每条都触发一次检测、一次事务、一次数据库往返。

改成批处理写法：

|---|---------------------------------------------------------------------------------------------------------------------------|
| | public static async Task InsertLogsBetterAsync(AppDbContext db, IReadOnlyList<InventoryLog> logs, CancellationToken ct) |
| | { |
| | const int chunkSize = 500; |
| | var original = db.ChangeTracker.AutoDetectChangesEnabled; |
| | |
| | try |
| | { |
| | db.ChangeTracker.AutoDetectChangesEnabled = false; |
| | |
| | for (var i = 0; i < logs.Count; i += chunkSize) |
| | { |
| | var chunk = logs.Skip(i).Take(chunkSize).ToList(); |
| | db.InventoryLogs.AddRange(chunk); |
| | |
| | db.ChangeTracker.DetectChanges(); |
| | await db.SaveChangesAsync(acceptAllChangesOnSuccess: false, ct); |
| | db.ChangeTracker.AcceptAllChanges(); |
| | db.ChangeTracker.Clear(); |
| | } |
| | } |
| | finally |
| | { |
| | db.ChangeTracker.AutoDetectChangesEnabled = original; |
| | } |
| | } |

这段代码做了四件关键事：

• 关闭自动检测，避免高频重复扫描
• 分块提交，控制单次事务与参数规模
• 手动确认状态，异常时更可控
• 每批清理跟踪器，防止上下文越跑越重

如果你要快速观察当前跟踪压力，可以加一个轻量诊断：

|---|------------------------------------------------------------------------------------------|
| | public static void DumpTrackerStats(DbContext db) |
| | { |
| | var entries = db.ChangeTracker.Entries().ToList(); |
| | |
| | Console.WriteLine($"Tracked: {entries.Count}"); |
| | Console.WriteLine($"Added: {entries.Count(e => e.State == EntityState.Added)}"); |
| | Console.WriteLine($"Modified: {entries.Count(e => e.State == EntityState.Modified)}"); |
| | Console.WriteLine($"Deleted: {entries.Count(e => e.State == EntityState.Deleted)}"); |
| | } |

压测结果（AB 实测）

我用单机服务和数据库，用 AB 模式完整跑了一轮，对照组先跑，再跑实验组。核心数据如下：

指标	数值
总请求数	5190
吞吐 RPS	8.23
成功吞吐 RPS	8.07
错误率	1.93%
端到端耗时 P95	944 ms
成功路径 P95	861 ms
成功路径平均	480 ms
失败路径 P95	30079 ms
失败-超时次数	100
AB 对比 - bad P95	30079 ms
AB 对比 - better P95	861 ms
AB 对比 - P95 改善	97.14%

这组数据已经很有说服力：

• better 在同样压测条件下，慢请求耗时明显更稳，P95 从 30s 档位直接回到 1s 内。
• 错误主要是超时型失败，不是业务逻辑错误，这通常意味着写入链路组织方式把数据库往返拖慢了。
• 成功路径平均 480ms，但整体平均被 30s 级别超时样本拉高，说明少量慢失败对整体体验影响非常大。

一句话总结：这次 AB 结果证明，优化写入组织方式（分块 + 减少无效变更检测）比单纯堆数据库资源更直接。

实践建议

一个请求一个 DbContext，别跨批次复用

这个点看着普通，但特别容易被忽略。DbContext 活得越久，里面挂着的实体越多，SaveChanges 就越容易变慢，偶发抖动也会变多。

批量写入先分块，别一口气全塞进去

可以先从每批 200~1000 条开始压测，再按你们库的参数上限、锁等待情况慢慢调。别追求一步到位，先跑稳再提速。

总结

EF Core 写入性能不是一个"开关问题"，而是一条链路问题。