EF Core 批量更新的核心是绕过实体加载和变更跟踪，直接生成 sql UPDATE 语句执行；从 EF Core 7 起推荐使用 ExecuteUpdate，需配合 Where 筛选、SetProperty 设置字段，返回影响行数，不支持导航属性和模型验证。
EF Core 批量更新的核心是绕过实体加载和变更跟踪，直接生成一条 SQL UPDATE 语句执行。从 EF Core 7 开始，ExecuteUpdate 成为官方推荐的高效方式，比传统 SaveChanges 快数倍甚至百倍——尤其在更新上千条记录时效果明显。
用 ExecuteUpdate 实现真正批量更新
它不查数据、不建实体、不走变更追踪，只拼一条带 WHERE 条件的 UPDATE 语句发给数据库：
- 必须配合
.Where(...)筛选目标记录，否则会全表更新（危险！） -
SetProperty支持字段直赋值，也支持表达式计算（如p => p.Price * 1.1m） - 可链式调用多个
SetProperty，一次更新多个字段 - 返回影响行数，便于业务校验
示例：把所有待处理订单状态改为“处理中”，并更新时间
context.Orders
.Where(o => o.Status == “Pending”)
.ExecuteUpdate(setters => setters
.SetProperty(o => o.Status, “Processing”)
.SetProperty(o => o.LastUpdated, DateTime.UtcNow));
避免常见错误的实操要点
很多性能问题其实源于误用，不是方法不行，而是没踩对点：
- 别在
ExecuteUpdate前调用.ToList()或.AsEnumerable()，那会先查出全部数据，彻底失去批量意义 - 条件写错会导致误更新，上线前建议用
ToQueryString()打印 SQL 预览：
var sql = context.Orders.Where(…).ToQueryString(); - 不能更新导航属性或复杂子对象，只支持本表标量字段（如 string、int、DateTime）
- 不触发模型验证、不执行
SaveChanges的拦截器（如SaveChangesAsync中的逻辑），需自行补业务逻辑
什么时候该用其他方案？
ExecuteUpdate 虽快，但有适用边界。遇到以下情况，可考虑替代方案：
- 要更新的数据来自外部集合（比如导入的 excel 列表），没有现成 WHERE 条件 → 用 EFCore.BulkExtensions 的
BulkUpdate - 需要同时插入+更新+删除（即 upsert），且逻辑复杂 →
ExecuteUpdate不支持，用BulkMerge或原生 SQL - 数据库版本低于 EF Core 7，或项目暂不能升级 → 可用
ExecuteSqlRaw手写 SQL，或引入 Dapper 处理写密集场景
小技巧：动态控制更新字段
实际业务中常需“按配置决定更新哪些字段”，可用条件判断灵活构建 SetProperty：
var builder = context.Users.Where(u => u.LastLogin var result = builder.ExecuteUpdate(setters =>
{
var update = setters;
if (shouldLock) update = update.SetProperty(u => u.IsLocked, true);
if (shouldResetVersion) update = update.SetProperty(u => u.Version, 0);
return update;
});
这样既保持代码清晰，又避免空字段误覆盖。
基本上就这些。核心就一条：让更新逻辑尽可能靠近数据库，越少中间环节，越快越稳。