我最初注意到AsNoTracking()是在一个数据采集项目里。那个项目用EF Core做点位配置管理点位表大概八千多条记录上位机每两秒轮询一次配置同时还有历史数据查询。跑了一个多小时后进程内存从三百多兆涨到七百多兆界面操作开始发卡。我当时的第一反应是对象没释放、连接没关闭排查了一圈才发现问题出在EF Core的默认跟踪机制上。给查询加上AsNoTracking()之后内存曲线立刻平稳了问题当场解决。这篇文章不打算从官方文档的角度复述AsNoTracking()的概念那东西MSDN上写得很清楚。我想聊的是我在实际项目里对它的理解它到底在省什么开销、性能差距有多大、适用边界在哪里、有哪些容易踩的坑以及它在EF Core 5.0之后的一些进阶用法。如果你也在用EF Core做上位机、报表、接口服务这类读多写少的系统这篇文章应该能帮你少走不少弯路。1. 默认跟踪到底在干什么先搞懂EF Core的记账本1.1 跟踪不是玄学是EF Core的记账本EF Core的DbContext在默认配置下查询出来的实体都会被跟踪。跟踪这个词听着玄本质上是DbContext针对每个实体实例建立的一套记账机制记账的内容包括这个实体实例对应数据库中的哪一行主键这个实体实例加载时的原始属性值原始值快照这个实体实例当前的最新属性值当前值这个实体的状态Unchanged、Modified、Added、Deleted、Detached为什么要记这些账因为EF Core需要实现对象变数据库跟着变的能力。你在代码里执行product.Price 99.9m;EF Core并不是立刻知道这个改动它要靠SaveChanges()时对跟踪的实体做体检——拿当前值和原始值逐属性比对检测出哪些属性被改过然后生成对应的UPDATE语句。用一个比较生活化的类比跟踪就像你逛超市时收银员始终跟着你记下你从货架上拿走了什么、放回过什么。结账时不需要你回忆她手里的清单就是依据。如果你只是进来看看价格只读查询完全不需要收银员跟着——这就是AsNoTracking()存在的意义它会告诉EF Core这批实体只是路过不用记账。1.2 被跟踪实体的三项隐藏开销很多人以为跟踪的代价只是多存一份快照其实不止。真正被忽视的有三个开销第一原始值快照的内存开销。每个被跟踪的实体EF Core都要额外维护一组原始值。对于包含几十个属性的实体来说这部分内存占用是实打实翻倍的。我在一个测试里查了十万条记录默认跟踪的内存占用约280MB改成AsNoTracking()之后约110MB差距直接超过一倍。注意这个数据是在我的开发机上用.NET 6 SQL Server跑出来的不同机器不同数据库会有差异但量级关系是稳定的。第二变更检测的时间开销。SaveChanges()的时候EF Core需要遍历所有被跟踪实体逐个属性去比较当前值和原始值。实体数量越大这次遍历越耗时。你可能觉得SaveChanges又不是频繁调用能慢到哪去但如果你在一个长时间运行的服务里不断查询却不清理DbContext被跟踪实体会越积越多——这就是我那个项目内存飙升、操作发卡的直接原因。第三Identity Resolution标识解析的限制。同一个DbContext里主键相同的实体只允许有一个实例。这个是EF Core为了保证一致性做的约束但它也是隐形成本每次查询都要做主键匹配去重。更麻烦的是如果你两次查询使用不同的Include组合后查询的结果会复用先前查询缓存的实例有时候会带来一些看起来像Bug的关联数据混乱。1.3 判断是否需要跟踪一条最简单的标准要不要跟踪其实不需要记那么多规则。我自己的判断标准只有一条这批实体在后续有没有可能被修改并写回数据库如果答案是没有就尽量不加跟踪如果答案是可能有就老老实实跟踪。这条标准在绝大多数情况下都是成立的。唯一的例外是延迟加载导航属性——后面我会单独讲这个坑。纯展示型列表、报表统计、配置快照、历史数据查询这些场景在查询完成后基本不会再动实体完全可以不加跟踪。2. 上位机轮询场景的实测加了AsNoTracking()之后2.1 原始代码长什么样先还原一下我当时那个坑。项目是典型的C#上位机架构后台Service每两秒轮询一次数据库把点位配置加载到内存缓存里供界面绑定和数据采集线程使用。代码大概是这样的public async TaskListPointConfig LoadPointConfigsAsync() { await using var dbContext _dbContextFactory.CreateDbContext(); return await dbContext.PointConfigs .Where(p p.IsEnabled) .OrderBy(p p.ChannelId) .ThenBy(p p.Address) .ToListAsync(); }注意这个方法是两秒钟被调用一次每次都是新建DbContext。按说DbContext用完就释放了跟踪的实体应该跟着被回收为什么内存还会一直涨问题出在两方面。一方面上位机的操作界面和报表查询是并行的界面绑定的集合、历史查询结果、报警记录这些查询都是默认跟踪每分钟产生几千个被跟踪实体。另一方面.NET的GC回收有延迟高频分配大对象后内存曲线往往是锯齿状上升不会立刻降下来。如果服务端还做了缓存把查询结果存到静态字典里那被跟踪实体就彻底没法回收了——因为缓存持有的是实体引用而实体内部还挂着DbContext的跟踪快照。2.2 实测数据对比为了验证是不是跟踪的锅我写了一个对照组用的还是上面这个查询只加了一个方法调用return await dbContext.PointConfigs .AsNoTracking() .Where(p p.IsEnabled) .OrderBy(p p.ChannelId) .ThenBy(p p.Address) .ToListAsync();区别就只有一行AsNoTracking()。实际跑下来两组数据差异明显以下是我在开发机上的实测值数据量12000条、实体包含约30个字段、连续执行100次取平均值指标默认跟踪AsNoTracking()单次查询平均耗时约 320ms约 260ms100次后进程内存增量约 780MB约 340MBSaveChanges遍历10000条实体耗时约 85ms不适用耗时差距看起来没那么夸张大概百分之二十左右但内存差异是数量级的。在长时间运行的上位机里内存才是要命的问题——内存一高GC频繁触发界面卡顿、采集线程延迟全来了。另外还有一个很多人没注意到的点如果后续你把这个查询结果直接塞给界面做绑定默认跟踪的实体在UI线程上被集合反复操作时EF Core的变更检测也会在幕后做无用功。这部分开销不计入查询耗时但对整体性能是实打实的拖累。2.3 为什么SQL没变却变快了这里必须澄清一个常见的误解。AsNoTracking()对生成的SQL没有任何影响。同一个查询加不加AsNoTracking()发到数据库的SQL语句一模一样。它省的不是数据库执行时间而是EF Core在客户端做的事不创建原始值快照省内存不执行Identity Resolution去重省CPU实体状态直接是Detached不参与SaveChanges的变更检测所以在传统瓶颈在数据库的场景里你可能感觉不到查询变快了。但在瓶颈在内存/GC/客户端处理的场景里AsNoTracking()的效果会非常明显——尤其是数据量大、实体字段多、查询频繁的服务。这也是为什么我总跟人说它不是为了优化数据库查询而是为了优化你的应用程序自身。3. 适用边界什么时候可以放心加什么时候千万别加3.1 读多写少的只读场景放心加适合加AsNoTracking()的场景我总结下来大概有四类数据展示型列表包括上位机界面、Web后台列表、报表导出。这类查询结果只做显示用户改了也是走独立的更新接口不会直接SaveChanges这些实体。配置快照加载。就像我文章开头那个点位表加载出来是为了在内存里做映射、做业务判断不会改数据库。历史数据查询。上位机里最常见的就是历史趋势、报警查询数据只读。缓存数据预热。往内存缓存里灌数据时加上AsNoTracking()能让缓存里不残留DbContext的跟踪状态避免DbContext释放后缓存数据还惦记着一个已经销毁的跟踪器。在这些场景里加AsNoTracking()不仅是性能优化更是一种架构上的防御——它帮你把只读数据和可写数据在语义上区分开了。3.2 要写回数据库的场景千万别加下面这些场景加AsNoTracking()会出问题我列一下查询出来之后要修改字段再SaveChanges()。如果你用AsNoTracking()把实体查出来改属性SaveChanges()会发现DbContext根本不知道有这号实体变更不会生效甚至直接报错。级联删除和关系操作。比如你把一个订单实体NoTracking出来然后想通过设置导航属性把订单项关联进去再保存EF Core因为不跟踪根实体关联关系无法被正确识别。延迟加载。凡是依赖延迟加载获取导航属性的查询绝对不能加AsNoTracking()。这个机制依赖代理和跟踪NoTracking状态下导航属性就是null运行时你只会拿到一个NullReferenceException。3.3 混合页面/接口的正确拆法实际项目里一个接口只做纯查询的情况其实很少更多时候是查出来一部分用于展示、另一部分需要改。我的做法是按语义拆分而不是对整个接口一刀切。比如一个编辑界面进入页面时要加载一个主实体和它的子项列表保存时要把修改写回。我会把加载主实体用默认跟踪因为保存时需要它把加载子项列表用AsNoTracking()因为子项列表是绑定给只读表格的保存时我会单独处理。代码结构类似var order await dbContext.Orders.FirstAsync(o o.Id id); // 需要跟踪保存用 var orderItems await dbContext.OrderItems .Where(i i.OrderId id) .AsNoTracking() // 只读展示用 .ToListAsync();混合使用是完全合法的别以为一个DbContext里要么全部跟踪、要么全部不跟踪。数据库不需要你保持状态一致跟踪与否是每个查询独立决定的。不过要注意混合使用时别把NoTracking查出来的实体挂到Tracking实体的导航属性上再SaveChanges否则EF Core会尝试把Detached的实体也Insert进去行为很反直觉。4. 进阶技巧AsNoTrackingWithIdentityResolution()与全局配置4.1 EF Core 5.0引入的折中方案AsNoTracking()有一个副作用容易被忽略它跳过了Identity Resolution也就是说同一个主键如果在一个查询结果里多次出现会生成多个不同的实例。大部分情况下这无所谓但如果你手动做关联处理比如把主实体和子项分组、或者用了Select投影后再拼装实例不唯一可能带来引用判断上的麻烦。EF Core 5.0引入了AsNoTrackingWithIdentityResolution()它的效果是不跟踪、不创建快照、不参与变更检测但保留Identity Resolution——同一个DbContext实例里相同主键的实体只会被实例化一次。代价是它内部会维护一个轻量级的标识映射表内存开销比纯AsNoTracking()稍高一点但比默认跟踪低得多。官方文档的说法是它适合大量实体需要一次性加载又要做关联处理的场景比如导入导出、报表汇总前的手工关联。我的使用建议如果场景里需要按主键对查询结果做Dictionary聚合或者要多次查询同一批主键并把结果合并就用AsNoTrackingWithIdentityResolution()如果只是列表展示用普通AsNoTracking()就够了没必要多付那一点去重的开销。4.2 全局默认NoTracking的配置方式如果整个项目就是查多写少还可以在DbContext级别把默认行为改掉让所有查询默认就是NoTracking个别需要追踪的查询再单独AsTracking()protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer(connectionString) .UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking); }如果用的是依赖注入注册DbContext的方式则在AddDbContext里面配置services.AddDbContextAppDbContext(options { options.UseSqlServer(connectionString); options.UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking); });全局默认NoTracking之后所有查询都变成Detached状态需要写回的地方要显式调用AsTracking()、Attach()或者设置Entity.State EntityState.Modified。这里我踩过一个坑全局改了默认行为之后有个更新接口一直不生效排查半天才发现是查询没加AsTracking()实体是Detached状态SaveChanges时压根不知道要更新哪一行。所以凡是改动全局配置的行为要把所有写路径都过一遍标注清楚哪些查询需要Tracking。4.3 和投影、分页查询搭配的细节这里再补充几个搭配细节。无实体结果时AsNoTracking()没实际意义但无害。比如你用的是Select投影出一个匿名对象或DTO这类查询本身就没有实体被跟踪加不加都一样。我的习惯是投影查询不加保持代码简洁如果团队规范要求统一加也无妨。分页查询搭配时要注意分两步的标准写法Count查询和ToList查询分别执行。这两个查询各自加不加AsNoTracking()互不影响但Count查询本质上是个聚合没有实体加不加都行。真正要注意的是分页后续是否对每页数据做修改——如果是批量编辑页面编辑的那一页要用Tracking查询纯列表页用NoTracking。还有人说NoTracking能和AsSplitQuery()拆分查询搭配使用这个组合没问题。AsSplitQuery()解决的是Include多个集合时笛卡尔积爆炸的问题它和跟踪与否是两个维度可以同时加。实测过一个复杂查询同时用两者耗时从原来的8秒降到3秒左右一个维度是去掉了重复连接数据另一个维度是省掉了客户端跟踪开销两者是叠加关系。5. 实战踩坑实录排查链路的完整复盘5.1 坑一NoTracking后更新静默失败这个坑我在4.2里提过一嘴这里展开讲完整排查过程。场景是设备管理模块用户修改设备名称后点保存。代码是先查询再更新var device await dbContext.Devices .AsNoTracking() .FirstAsync(d d.Id deviceId); device.Name newName; await dbContext.SaveChangesAsync();第一版代码一直没问题后来有人把全局默认行为改成了NoTracking这个保存接口就开始静默失败——不报错、不异常、数据库里名字不变。排查链路是这样的先看SaveChanges返回的受影响行数发现返回0说明生成的UPDATE语句匹配不到行。再看生成的SQL发现UPDATE语句带了WHERE Id ... 和原始值条件但EntityState是DetachedEF Core压根没把它加入跟踪集合。最后看全局配置定位到了QueryTrackingBehavior.NoTracking。修复方案有两种一是查询时显式加AsTracking()二是查询后手动把状态改成ModifieddbContext.Entry(device).State EntityState.Modified; await dbContext.SaveChangesAsync();这里提醒一句改成Modified这种写法要小心它会把所有列都更新而不是只更新变化的列。如果你想只更新有变化的列还是老老实实用跟踪查询。5.2 坑二导航属性变成null的真相第二个坑出现在报表模块。我写了一个订单和订单明细的查询为了让界面显示订单关联的客户名称加了Includevar orders await dbContext.Orders .Include(o o.Customer) .AsNoTracking() .ToListAsync();这个查询其实没问题Include的导航属性会被预先加载NoTracking下也能正常访问。但后来有人把Include删了改成依赖延迟加载var orders await dbContext.Orders.AsNoTracking().ToListAsync(); // 之后访问 orders[0].Customer 时报NullReferenceException这也是延迟加载最典型的翻车现场。延迟加载的原理是导航属性被访问时EF Core通过DbContext去数据库查询对应的关联数据。前提是这个实体必须被跟踪且DbContext还活着。NoTracking状态下实体是DetachedEF Core根本没有上下文可以帮你去查询所以导航属性永远是null。这个坑的排查和修复都简单但很多人会栽在删了Include就报错上不知道背后的机制。我的建议是只读列表的关联数据一律用Include或ThenInclude显式加载别依赖延迟加载。延迟加载在NoTracking场景下就是定时炸弹。5.3 坑三分页Count和ToList结果对不上第三个坑更隐蔽出现在一次报表分页查询里。代码长这样var query dbContext.Alarms .Where(a a.Time start a.Time end) .AsNoTracking(); int total await query.CountAsync(); var page await query .OrderByDescending(a a.Time) .Skip(pageIndex * pageSize) .Take(pageSize) .ToListAsync();看上去没问题但实际发现total有时比page的ToList结果数量还大甚至出现明明统计了100条却只能查到80条的现象。这里其实和AsNoTracking()没直接关系问题出在同一个IQueryable被二次执行时EF Core在无跟踪状态下不保证结果稳定——因为在查询执行间隙可能有别的线程对数据做了删除或修改。而且更深一层的原因是我对同一个query复用了查询表达式第二次ToList前又追加了排序和分页第一次Count和第二次ToList不是同一批数据。排查思路是把Count和ToList拆成两个独立查询Count只做聚合分页部分重新构建临时的IQueryableint total await dbContext.Alarms .CountAsync(a a.Time start a.Time end); var page await dbContext.Alarms .Where(a a.Time start a.Time end) .AsNoTracking() .OrderByDescending(a a.Time) .Skip(pageIndex * pageSize) .Take(pageSize) .ToListAsync();这个坑其实和NoTracking关系不大但很多人在排查NoTracking相关问题时容易归错因。在这里我把完整过程记录下来是想说明一个排查方法论遇到查询结果和预期不一致先确认是SQL层面的问题数据本身变了还是跟踪层面的问题实体状态、实例重复再找对应的解决方案。5.4 一个通用的排查思路怎么证明你的查询被跟踪了最后分享一个实用的排查方法。判断一个查询返回的实体是否被跟踪最快的方式是看状态var entity await dbContext.Products.FirstAsync(p p.Id 1); var state dbContext.Entry(entity).State; // 默认跟踪时输出 UnchangedNoTracking时输出 Detached如果你怀疑某个查询的实体被意外跟踪了但代码里没有显式加AsTracking可能是全局配置或查询拦截器干的。用上面这个方法逐点验证比看配置文件更直接。另外抓EF Core生成的SQL有个办法就是配置日志optionsBuilder.LogTo(Console.WriteLine, LogLevel.Information);日志里能看到每一条查询语句以及DetectChanges这类关键事件有助于判断性能瓶颈是不是出现在客户端跟踪上。我自己在项目里用AsNoTracking()的习惯已经固定成一条规则写操作路径上的查询一律默认跟踪只读展示路径上的查询一律显式加AsNoTracking()全局默认只会在绝大多数查询都是只读的报表服务里启用并且会在代码评审时把每个写路径都标出来。这个方法不复杂但它的价值常常被低估——在长生命周期、高频率查询的应用里多留意一下跟踪状态省下的内存和GC压力是实打实的。如果你的项目也出现了数据量不大但内存一直涨界面查询越用越卡这类问题不妨先查一查是不是被EF Core默默跟踪了一堆根本不会修改的实体。