ExecuteUpdate 是 EF Core 7+ 官方推荐的批量更新方式，不加载实体、不走变更跟踪、只生成一条 SQL UPDATE 语句；它跳过查询与内存修改，直接拼 SQL，性能远超 SaveChanges，但依赖 WHERE 条件正确使用索引。
ExecuteUpdate 是 EF Core 7+ 官方推荐的批量更新方式，它不加载实体、不走变更跟踪、只生成一条 SQL UPDATE 语句——只要 Where 条件写对，万级更新通常在毫秒级完成。
为什么 ExecuteUpdate 比 SaveChanges 快得多
传统 SaveChanges 更新本质是“查出来 → 改内存对象 → 对比快照 → 逐条生成 UPDATE”；而 ExecuteUpdate 跳过前两步，直接拼 SQL：
- 不触发
ChangeTracker，无快照比对开销 - 不实例化任何实体，内存占用趋近于零
- 无论更新 10 行还是 10 万行，都只发一次数据库请求
- 不会调用
ValueConverter、模型验证、SaveChangesInterceptor
典型性能差距：SaveChanges 更新 10,000 条记录约 8 秒，ExecuteUpdate 同样操作约 0.4 秒。
SetProperty 必须写成链式调用，不能用 new 实体赋值
ExecuteUpdate 接收的是 SetProperty 链，不是构造新实体。下面这种写法会编译失败：
context.Orders.Where(x => x.Status == "Pending")
.ExecuteUpdate(x => new Order { Status = "Processing", UpdatedAt = DateTime.UtcNow }); // ❌ 编译报错正确写法是显式调用 .SetProperty()：
context.Orders.Where(x => x.Status == "Pending")
.ExecuteUpdate(setters => setters
.SetProperty(o => o.Status, "Processing")
.SetProperty(o => o.UpdatedAt, DateTime.UtcNow)); // ✅关键点：
- 每个
SetProperty只能指定一个属性和它的新值（或表达式） - 支持简单计算：如
.SetProperty(o => o.Price, o => o.Price * 1.1m) - 不支持方法调用（
.ToUpper()）、导航属性（o.Customer.Name）、条件三元运算符（o => o.IsActive ? "Y" : "N"） - 字段名必须是当前
DbSet对应实体的**直接映射标量属性**
Where 条件不走索引，再快的方法也变慢
ExecuteUpdate 性能完全取决于数据库是否能用索引快速定位目标行。常见陷阱：
-
Where(x => x.CreatedDate.Date == DateTime.Today)—— 对字段用函数，索引失效 -
Where(x => x.Status == "Archived" && x.CreatedDate > cutoff)—— 若联合索引是(CreatedDate, Status)，这个顺序无法利用索引 -
Where(x => EF.Functions.Like(x.Name, "%abc%"))—— 左模糊，基本无法走索引
上线前务必检查执行计划。调试时可先打印 SQL：
var sql = context.Orders.Where(x => x.Status == "Pending").ToQueryString(); Console.WriteLine(sql); // 输出类似：UPDATE [Orders] SET [Status] = N'Processing' WHERE [Status] = N'Pending'
执行后拿不到被更新的实体，影响行数要自己校验
ExecuteUpdate 返回的是 int 类型的影响行数，不是实体列表：
int affected = context.Users
.Where(u => u.LastLogin < DateTime.Now.AddMonths(-6))
.ExecuteUpdate(setters => setters
.SetProperty(u => u.IsActive, false)
.SetProperty(u => u.Version, u => u.Version + 1));
<p>if (affected == 0) {
// 业务上可能需告警：本该下线一批用户，但没匹配到任何记录
}注意：
- 返回值是数据库实际修改的行数，不是“预期数量”，可用于防误操作
- 若上下文里已有同主键的
Added或Modified实体，执行会直接抛InvalidOperationException - 不触发
OnDeleting/OnUpdated等生命周期钩子，相关逻辑得提前补在业务层
真正难的不是写对语法，而是确认 WHERE 条件在生产库上是否真的走了索引、有没有意外匹配到不该动的数据——这一步漏掉，批量更新就从提效变成事故。
