单DbContext放全部DbSet会导致SaveChanges执行慢吗？优化最佳实践是什么？

核心结论 #

将所有DbSet放在同一个DbContext本身不属于不良实践，你遇到的SaveChanges()性能问题和DbSet的数量没有直接关联，核心根源是DbContext的生命周期管理不当、变更跟踪器累积了大量无关实体。你测试的仅包含单个DbSet的Context更快，本质是因为该Context是新建的、没有累积大量被跟踪的实体，而非DbSet更少带来的性能提升。

SaveChanges()执行速度的决定因素 #

• 变更跟踪器扫描开销：调用SaveChanges()时EF Core会默认扫描所有被当前Context跟踪的实体，判断每个实体的增删改状态，跟踪的实体数量越多，扫描耗时越长。WPF项目中如果长期持有同一个DbContext（比如设为全局单例），会导致跟踪器日积月累累积数万甚至数十万无关实体，单次扫描耗时很容易达到数秒级别。
• 单次提交的变更数量：单次SaveChanges()提交的增删改操作越多，生成的SQL语句越多、数据库执行事务的耗时越长。
• 配置项影响：你的代码中开启了UseLazyLoadingProxies()，会导致访问实体导航属性时自动加载关联实体，很容易在不知情的情况下加载大量无关实体到跟踪器中，进一步放大变更扫描的开销。
• 数据库端性能：数据库表的索引设计、锁冲突、事务隔离级别也会影响最终提交耗时。

适配你项目场景的优化最佳实践 #

• 优先修改DbContext的生命周期管理：WPF项目不要全局复用同一个DbContext，改为按业务操作单元创建短生命周期的DbContext，操作完成后立即释放。比如处理订单相关操作时才实例化MyDbContext，调用SaveChanges()后直接Dispose，这样跟踪器中永远只有当前操作相关的少量实体，变更扫描开销会直接下降到和你测试的单DbSet Context同一水平。
• 非修改类查询添加AsNoTracking()：仅用于展示、不需要修改的查询，统一调用AsNoTracking()扩展方法，例如myDbContext.Orders.AsNoTracking().Where(x => x.CreateTime > DateTime.Now.AddDays(-7))，查询返回的实体不会被加入变更跟踪器，既节省内存也不会拖慢后续SaveChanges()的速度。
• 批量操作场景关闭自动变更检测：如果需要批量处理大量实体，可以在操作前设置myDbContext.ChangeTracker.AutoDetectChangesEnabled = false，所有实体操作完成、准备调用SaveChanges()前手动执行myDbContext.ChangeTracker.DetectChanges()，操作完成后恢复配置，可大幅减少频繁触发变更检测的开销。
• 按需拆分限界上下文：如果你的业务模块之间关联性极低，可以按领域边界拆分多个小的DbContext（而非按单表拆分），比如订单模块的Context仅包含订单、订单明细、关联的客户、商品等必要的DbSet，库存模块的Context仅包含库存相关的DbSet，进一步降低每个Context的复杂度，符合领域驱动设计的规范。
• 批量增删改用原生批量操作：EF Core 7及以上版本内置了ExecuteUpdate()、ExecuteDelete()方法，不需要将实体加载到跟踪器中即可直接在数据库端执行批量操作，性能比先查实体再修改提交高10~100倍。
• 替换不必要的懒加载：如果不需要全局使用懒加载，可以关闭UseLazyLoadingProxies()配置，改为用Include()预加载或者Reference()/Collection()显式加载关联实体，避免意外加载大量无关数据。

内容的提问来源于stack exchange，提问作者sgk151