每次看到群里有人贴出分页查询越查越慢的截图或者半夜被线上接口超时告警吵醒我第一反应就是先问一句查询加AsNoTracking()了吗在C#的EF Core开发里这个问题出现的频率高得惊人。AsNoTracking()是Entity Framework Core中一个看似简单、实则能救命的方法它解决的核心问题就是当你的查询结果只是为了展示、统计、导出压根不打算改完再存回去时EF Core却默认帮你做了大量毫无意义的跟踪工作白白消耗性能。这篇博文不打算写成API文档的搬运工我会从EF Core的跟踪机制讲起再到源码级别的性能差异分析最后用实测数据告诉你什么时候该用、什么时候千万不能用。内容覆盖从.NET Core 3.1到.NET 8的版本差异适合刚入门想搞懂原理的新人也适合已经在项目里被性能问题折磨、想系统排查一遍的老手。我会把实际项目中踩过的坑、优化前后的对比数据、以及AsNoTrackingWithIdentityResolution这些进阶玩法的取舍都聊清楚。1. 先搞明白EF Core为什么要跟踪实体很多初学者第一次接触AsNoTracking()只记住了它能提高性能但完全不知道为什么。这不行不理解原理就乱用迟早会在更新数据时踩大坑。这一节我们先把你可能会踩的坑给填上。1.1 状态管理器与快照EF Core的人工智障式监控EF Core的DbContext内部有一个状态管理器ChangeTracker它负责记录每个被查询出来的实体处于什么状态。状态有四种Detached未跟踪、Unchanged未修改、Modified已修改、Added新增、Deleted已删除。默认情况下你从数据库查出来的实体处于Unchanged状态但别以为这个状态就完事了状态管理器还在后台悄悄干了两件事。第一件事是保存快照。EF Core在实体被查询出来时会把每个属性的原始值存一份。等你调用SaveChanges()时它会拿出当前值和原始快照做逐属性比较。有差异好生成一条UPDATE语句只更新有变化的字段。第二件事是维护导航属性之间的引用关系。比如你查了Order又查了关联的Customer状态管理器会保证这两个实体互相引用的关系是对的方便你直接操作。听起来是不是挺贴心但问题在于这套机制不是白干活的。快照比较、状态标记、关系修复这些操作在实体数量少时没什么感觉可一旦进入批量查询场景——比如一次拉5万条日志、导出10万行报表状态管理器就成了不折不扣的性能杀手。你就想象一下Excel里每个单元格都有一个人工智障盯着的场景它动不动就全表对照一次能不卡吗1.2 跟踪开销到底有多大一个被低估的性能黑洞我经常拿一个实际项目数据跟同事算账。假设你有一个订单明细表单条记录20个字段你用默认方式查询1万条数据。EF Core需要为这1万条记录创建快照对象每个快照里保存20个属性的原始值同时还要把实体注册进状态管理器的字典里做身份解析Identity Resolution。这里有个你可能没留意过的细节EF Core的跟踪是按实体类型主键值建立索引的它必须检查字典里是否已存在相同主键的实体。我用BenchmarkDotNet跑过一组基准测试查询1万条记录默认跟踪方式的耗时大约是AsNoTracking()的2.5到3倍内存分配更是相差4倍以上。这还是在单次查询的情况下。如果你的接口是每秒被调用几十次的列表页这个差距会被无限放大最后的结果就是CPU飙升、GC频繁触发、接口响应越来越慢。2. AsNoTracking()的作用原理与适用场景明白了默认跟踪的代价我们来看正主。AsNoTracking()不是啥黑魔法它只是告诉EF Core这次查询出来的实体你不用管我我不改也别盯直接给我数据就行。2.1 一句话说清原理切断与状态管理器的连接当你在查询末尾加上AsNoTracking()EF Core会跳过以下几个步骤不为实体创建原始值快照不将实体注册进状态管理器不做身份解析除了后面要讲的AsNoTrackingWithIdentityResolution查询出的实体状态统一标记为Detached换句话说查询结果就是纯数据跟DbContext再无瓜葛。这些实体被返回后你就算改了它的属性EF Core也完全无感知调用SaveChanges()时不会生成任何更新语句。如果你用SQL语句理解默认跟踪查询相当于SELECT * FROM Orders而AsNoTracking()查询相当于SELECT * FROM Orders后EF Core顺手把返回的行直接扔给你别的不碰。从执行路径上看省掉了一大堆附加操作。2.2 典型的适用场景清单放心大胆地加在实际项目里遇到下面这些场景你可以毫无心理负担地加AsNoTracking()列表展示任何只读列表页、下拉框选项、树形结构数据查询完丢给前端就完事报表统计需要计算Sum、Count、GroupBy的聚合查询数据导出导出Excel、CSV时一次性拉取的大量数据DTO投影用Select()直接投影成DTO不返回实体类型缓存填充往Redis、MemoryCache里写入的数据本身就不需要被上下文跟踪这个清单是我个人做性能排查时的第一优先级检查项尤其是在分页接口上AsNoTracking()带来的提升是最明显、最立竿见影的。2.3 千万别用什么时候加了这个方法反而惹祸有适合的场景当然就有不适合的场景。下面这些情况你要是加了AsNoTracking()轻则数据更新不了重则出现难以察觉的业务逻辑bug。你如果查出实体后要修改它的属性并调用SaveChanges()保存那就绝对不能加。因为没跟踪修改不会被EF Core识别SaveChanges()什么都不做。而且更阴险的是你不会收到任何报错数据悄悄就没更新了。你如果需要在查询后级联操作导航属性比如order.Customer.Name xxx然后保存也容易出问题因为实体是Detached状态导航属性关联没有被正确修复。另外某些情况下EF Core会抛异常比如查询实体后用context.Entry(entity).State EntityState.Modified手动修改状态会提示无法跟踪实体因为已有相同主键的实体处于Detached状态。这个我在后面的排查章节会详细说。既然提到了场景区分我干脆做一张对比表放这儿方便你贴在工位上随时看。场景默认跟踪AsNoTracking读取列表展示浪费性能不报错推荐高效读取后修改保存推荐禁止静默失效读取后级联导航属性推荐可能报错DTO投影可以无效跟踪推荐大批量导出内存爆炸风险强烈推荐需要手动Attach修改无需额外操作需谨慎处理3. 实操从基础用法到性能实测对比光说不练假把式。这一节我直接上代码带你看看AsNoTracking()最常见的几种写法、性能实测数据以及一个日常大家可能不知道的升级版API。3.1 最基础的写法一行代码带来的改变最典型的用法就是在查询链式调用的末尾加上.AsNoTracking()using var context new AppDbContext(); // 基础用法不分页地查询大量只读数据 var logs await context.SystemLogs .AsNoTracking() .Where(l l.Level Error l.CreatedAt startTime) .OrderByDescending(l l.CreatedAt) .Take(10000) .ToListAsync(); // 投影DTO的做法即使投影也推荐加 var orderSummaries await context.Orders .AsNoTracking() .Select(o new OrderSummaryDto { Id o.Id, CustomerName o.Customer.Name, TotalAmount o.TotalAmount }) .ToListAsync();看到第二段代码有人可能会问我都投影成DTO了EF Core是不是天然就不跟踪了不完全对。EF Core确实在某些情况下会自动降级为无跟踪但在很多版本里如果实体类本身带有复杂的导航属性或者使用了某些集合操作还是会存在跟踪行为的。加AsNoTracking()就是明确表态不给EF Core任何犹豫的空间。3.2 实测数据1万条记录下到底差多少去年我优化一个工单查询接口顺手留下过一组基准测试数据。测试环境是.NET 8的WebAPISQL Server数据库单表1万条记录每条记录15个字段。我用BenchmarkDotNet连续跑了三组取中位数。查询方式耗时分派内存默认跟踪185.6 ms38.2 MBAsNoTracking()72.3 ms9.6 MBAsNoTrackingWithIdentityResolution()91.4 ms15.2 MB注意最后一行它是接下来的重头戏。3.3 进阶APIAsNoTrackingWithIdentityResolution从EF Core 2.1开始微软提供了一个既能无跟踪、又能做身份解析的方法AsNoTrackingWithIdentityResolution()。什么意思呢默认的AsNoTracking()是完全不管实体身份的如果你在同一个查询里多次查到了同一个主键的实体它们会表现为两个不同实例。这在某些场景下会让你的数据看起来有重复。而AsNoTrackingWithIdentityResolution()会在无跟踪的基础上额外做一次身份解析。比如你在查询Order时Include了Customer而同一个Customer有多条订单那么这个Customer在整个结果集里只会被实体化成一次所有相关订单都引用同一个实例。这非常有用。但代价就是它需要维护一个用于身份解析的字典性能介于默认跟踪和纯无跟踪之间。根据我的实测在包含导航属性的复杂查询里这个API的效果和性能是比较均衡的。3.4 全局配置省心的同时也要谨慎如果你觉得每个查询手动加太麻烦EF Core还提供了两种全局配置方式。第一种是在OnConfiguring中设置默认行为全项目生效protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder .UseSqlServer(connectionString) .UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking); }第二种是按上下文类型配置。设置后所有查询默认为无跟踪但如果你有特殊查询需要跟踪可以在单个查询上调用.AsTracking()覆盖回来。这个设计就很灵活了。我这里要说一句真心话全局配置虽然是好但我个人在实际项目中不太建议大家无脑全局开启。因为一旦设了全局NoTracking团队新成员很容易在需要更新数据时忘了加.AsTracking()然后就是一顿排查。我更推荐的做法是保持默认的跟踪行为让开发者在写代码时有意识地选择。只有在某个项目里已经明确所有查询都是只读、写操作被隔离到了独立的DbContext实例时全局配置才是合理的。4. 从源码层面看AsNoTracking的实现差异很多.NET开发者学过源码分析但对EF Core的内部实现比较陌生。我试着用通俗的方式讲一讲让你知道那个方法调用背后到底发生了什么。4.1 状态管理器的核心数据结构EF Core的ChangeTracker里有一个核心数据结构叫IDbContextSet说白了就是一个按实体类型分开存储的字典字典的键是实体主键值。当你执行默认跟踪查询时每读取一行数据EF Core都要查一次这个字典看这个主键是不是已经存在了。这就有意思了如果你查询了一个包含1万行的表每行的主键都不同那EF Core就要做1万次字典查找并往字典里插入1万个条目。这还只是数据加载阶段。加载完成后创建快照又是一项开销——不是你把当前值的引用存一下就行而是要复制一份完整的属性值集合这个集合用于后续的原始值比较。加上AsNoTracking()后查询内部直接把后续的状态跟踪流程跳过。加载数据时不会经历字典检查、注册和快照创建这些步骤。从一个很底层的行为角度去看两种方式下的查询执行计划是有差异的因为跟踪会影响EF生成的查询。这在后续的底部优化部分已经有很多测试验证过了。4.2 不跟踪时EF Core还做了哪些优化我挑一个特别容易被忽略的点投影优化。当你用Select投影DTO且加了AsNoTracking()时EF Core会更积极地对查询进行修剪。比如你只投影了3个字段EF Core生成的SQL可能就只SELECT这3列。但在默认跟踪模式下EF Core为了保证能恢复出完整实体有时候会额外把主键或外键字段也拉出来即使你没投影它们。这就是为什么有时候你加了AsNoTracking()除了省掉跟踪开销外SQL查询本身的返回列也会变少双重收益。4.3 一个容易误会的点AsNoTracking不会影响SQL执行有朋友可能误以为加了这个方法EF Core就会生成不同的SQL去减少扫描行数好像查询引擎会知道你只读不写然后做某种特殊优化。这个理解是不对的。AsNoTracking()影响的是EF Core的客户端行为与服务端SQL执行计划基本无关。生成的SQL还是同一个查询索引使用情况也是一样的它省的是在你拿到结果之前、EF Core在客户端为你做的附加工作。搞清楚这一点你就不会指望靠它来解决慢SQL问题——慢SQL该优化索引还是得优化索引。5. 常见踩坑与排查技巧实录这一节我整理了实战中最常碰到的几个问题。每个问题我都见过不止一次有些甚至是团队老手在特定场景下也会翻车的。5.1 问题一查询后修改不生效也没有任何报错这是最常见的坑。场景是这样的你查出实体改了属性调用SaveChanges()结果数据库毫无变化。排查了半天最后发现问题出在实体是Detached状态。我自己排查这个问题时有个习惯先查context.ChangeTracker.DebugView.ShortView如果实体状态全是Detached那基本可以断定是AsNoTracking()造成的。另外要注意如果你传递的是加了AsNoTracking()的查询结果且没有重新attach那个实体是不可能被EF Core感知修改的。解决办法要么查询时不加AsNoTracking()要么在修改前先把实体附加上context.Attach(order); // 从 Detached 转成 Unchanged order.Status Shipped; // 此时属性变更会被记录 await context.SaveChangesAsync();只修改部分字段的话用Attach后手动改Property状态也行。要提醒的是Attach会把所有属性都标记为Unchanged这样EF Core就只知道你要改指定字段了。5.2 问题二实体分离后导航属性加载异常另一个容易出问题的地方是导航属性。假设你查询时不加.Include()拿到一个Order实体访问order.Customer希望懒加载出客户信息。在默认跟踪模式下只要DbContext还没销毁EF Core可以自动把关联数据补齐。但加了AsNoTracking()且没有使用显式加载时这个懒加载经常会失败。因为实体不在状态管理器里EF Core缺失了必要的上下文线索。EF Core在检测这种访问时会抛出InvalidOperationException类似Cannot access navigation property because the entity is not being tracked。解决办法查询时用Include显式加载需要的导航属性改用AsNoTrackingWithIdentityResolution()并配合Include或者不要使用懒加载直接在项目中禁止懒加载用Include控制数据粒度我个人的建议是用Include显式加载不依赖懒加载。懒加载本身对性能不友好经常会触发额外的SQL查询。5.3 问题三手动附加时出现实体状态冲突这是一个比较隐蔽的问题。你先用AsNoTracking()查了一个实体然后又用同一个DbContext执行了另一个查询恰好返回了相同主键的实体并且是默认跟踪的。此时你再调用Attach去附加第一个实体就会报错The instance of entity type Order cannot be tracked because another instance with the same key value is already being tracked。为什么会这样因为状态管理器里已经有了一个相同主键的Order你没法再附加另一个。排查时需要查看是否在同一上下文里混用了跟踪和不跟踪的实体。解决办法尽量避免在同一个DbContext中混用两种模式查询同一张表。如果确实需要可以先用context.ChangeTracker.Clear()清理当前状态再执行附加操作。通过AsNoTracking()查出来的数据如果要进行修改我建议直接另起一个新的DbContext来做写操作干净省事。5.4 排查方法论一查二测三剖面跟AsNoTracking()相关的问题我总结了一个三步排查法。第一步查代码。用CtrlF搜一遍所有ToList()、ToListAsync()、FirstOrDefault()前面的查询看有没有AsNoTracking()。列出所有在查询后又要修改实体的地方逐点排查。第二步测响应。先用Stopwatch或MiniProfiler打点把一个查询的耗时拆成SQL执行时间和客户端处理时间。如果SQL执行时间没变而总耗时多了很多那大概率是跟踪开销。你也可以用SQL Server Profiler观察一下EF Core生成的SQL确认是不是有额外的列被查了出来。第三步剖面内存。在开发环境用 dotMemory 或者 Visual Studio 的诊断工具对比加不加AsNoTracking()的内存分配情况。这一步能直观地看到快照对象占了多少往往能让你更坚定地给相应查询加上这个方法。6. 我的一些经验和思考聊了这么多最后分享一点个人经验。我这几年做过的项目里凡是用EF Core处理过大量数据的地方基本都会贯彻这个原则只读查询和无状态查询一律AsNoTracking()写操作通过独立的工作单元处理。这样做的收益不只是性能更重要的是代码意图明确——能读不能改谁也不会在列表展示场景里误写更新逻辑。还有一个小习惯如果团队里有新人我会建议他们在写查询的时候先问自己一句话这批数据查出来之后会不会调用SaveChanges() 不会就加AsNoTracking()。会就别加。这个简单的问题能避免90%的误用。另外补充一个在分页查询中的实用技巧。如果你用的是EFCore的分页扩展库EFCore.Pagination或者自己写分页逻辑在页面上展示统计数据时建议同时使用两个查询一个是总数查询Count一个是当前页数据查询带AsNoTracking()。并且可以考虑将AsNoTracking()放到查询的最前面而不是最后因为EF Core在解析表达式树时无论方法放在链式调用的哪个位置最终都会合并到查询行为中。但为了可读性我习惯放在查询开头。说到底AsNoTracking()只是EF Core性能优化的一块基石。真正优秀的设计是你在写第一行查询代码时就清楚地知道哪些数据是状态哪些数据只是快照。把这两者分清楚你的系统在数据量增长时才有足够的底气不崩盘。最后还要再提一个容易被忽略的细节。当你使用ExecuteUpdate或ExecuteDeleteEF Core 7.0执行编译后的更新/删除操作时这些命令本来就不需要通过跟踪实体来执行。如果业务场景允许直接用这些方法替代查询实体再修改保存的老套路性能会有大幅提升。它们和AsNoTracking()一起用能让你的写操作也变得更干净利落。 
长河君 · 2026/10/11 7:14:05 · 阅读 1.2k EF Core性能优化：深入解析AsNoTracking原理、应用与避坑指南
每次看到群里有人贴出分页查询越查越慢的截图或者半夜被线上接口超时告警吵醒我第一反应就是先问一句查询加AsNoTracking()了吗在C#的EF Core开发里这个问题出现的频率高得惊人。AsNoTracking()是Entity Framework Core中一个看似简单、实则能救命的方法它解决的核心问题就是当你的查询结果只是为了展示、统计、导出压根不打算改完再存回去时EF Core却默认帮你做了大量毫无意义的跟踪工作白白消耗性能。这篇博文不打算写成API文档的搬运工我会从EF Core的跟踪机制讲起再到源码级别的性能差异分析最后用实测数据告诉你什么时候该用、什么时候千万不能用。内容覆盖从.NET Core 3.1到.NET 8的版本差异适合刚入门想搞懂原理的新人也适合已经在项目里被性能问题折磨、想系统排查一遍的老手。我会把实际项目中踩过的坑、优化前后的对比数据、以及AsNoTrackingWithIdentityResolution这些进阶玩法的取舍都聊清楚。1. 先搞明白EF Core为什么要跟踪实体很多初学者第一次接触AsNoTracking()只记住了它能提高性能但完全不知道为什么。这不行不理解原理就乱用迟早会在更新数据时踩大坑。这一节我们先把你可能会踩的坑给填上。1.1 状态管理器与快照EF Core的人工智障式监控EF Core的DbContext内部有一个状态管理器ChangeTracker它负责记录每个被查询出来的实体处于什么状态。状态有四种Detached未跟踪、Unchanged未修改、Modified已修改、Added新增、Deleted已删除。默认情况下你从数据库查出来的实体处于Unchanged状态但别以为这个状态就完事了状态管理器还在后台悄悄干了两件事。第一件事是保存快照。EF Core在实体被查询出来时会把每个属性的原始值存一份。等你调用SaveChanges()时它会拿出当前值和原始快照做逐属性比较。有差异好生成一条UPDATE语句只更新有变化的字段。第二件事是维护导航属性之间的引用关系。比如你查了Order又查了关联的Customer状态管理器会保证这两个实体互相引用的关系是对的方便你直接操作。听起来是不是挺贴心但问题在于这套机制不是白干活的。快照比较、状态标记、关系修复这些操作在实体数量少时没什么感觉可一旦进入批量查询场景——比如一次拉5万条日志、导出10万行报表状态管理器就成了不折不扣的性能杀手。你就想象一下Excel里每个单元格都有一个人工智障盯着的场景它动不动就全表对照一次能不卡吗1.2 跟踪开销到底有多大一个被低估的性能黑洞我经常拿一个实际项目数据跟同事算账。假设你有一个订单明细表单条记录20个字段你用默认方式查询1万条数据。EF Core需要为这1万条记录创建快照对象每个快照里保存20个属性的原始值同时还要把实体注册进状态管理器的字典里做身份解析Identity Resolution。这里有个你可能没留意过的细节EF Core的跟踪是按实体类型主键值建立索引的它必须检查字典里是否已存在相同主键的实体。我用BenchmarkDotNet跑过一组基准测试查询1万条记录默认跟踪方式的耗时大约是AsNoTracking()的2.5到3倍内存分配更是相差4倍以上。这还是在单次查询的情况下。如果你的接口是每秒被调用几十次的列表页这个差距会被无限放大最后的结果就是CPU飙升、GC频繁触发、接口响应越来越慢。2. AsNoTracking()的作用原理与适用场景明白了默认跟踪的代价我们来看正主。AsNoTracking()不是啥黑魔法它只是告诉EF Core这次查询出来的实体你不用管我我不改也别盯直接给我数据就行。2.1 一句话说清原理切断与状态管理器的连接当你在查询末尾加上AsNoTracking()EF Core会跳过以下几个步骤不为实体创建原始值快照不将实体注册进状态管理器不做身份解析除了后面要讲的AsNoTrackingWithIdentityResolution查询出的实体状态统一标记为Detached换句话说查询结果就是纯数据跟DbContext再无瓜葛。这些实体被返回后你就算改了它的属性EF Core也完全无感知调用SaveChanges()时不会生成任何更新语句。如果你用SQL语句理解默认跟踪查询相当于SELECT * FROM Orders而AsNoTracking()查询相当于SELECT * FROM Orders后EF Core顺手把返回的行直接扔给你别的不碰。从执行路径上看省掉了一大堆附加操作。2.2 典型的适用场景清单放心大胆地加在实际项目里遇到下面这些场景你可以毫无心理负担地加AsNoTracking()列表展示任何只读列表页、下拉框选项、树形结构数据查询完丢给前端就完事报表统计需要计算Sum、Count、GroupBy的聚合查询数据导出导出Excel、CSV时一次性拉取的大量数据DTO投影用Select()直接投影成DTO不返回实体类型缓存填充往Redis、MemoryCache里写入的数据本身就不需要被上下文跟踪这个清单是我个人做性能排查时的第一优先级检查项尤其是在分页接口上AsNoTracking()带来的提升是最明显、最立竿见影的。2.3 千万别用什么时候加了这个方法反而惹祸有适合的场景当然就有不适合的场景。下面这些情况你要是加了AsNoTracking()轻则数据更新不了重则出现难以察觉的业务逻辑bug。你如果查出实体后要修改它的属性并调用SaveChanges()保存那就绝对不能加。因为没跟踪修改不会被EF Core识别SaveChanges()什么都不做。而且更阴险的是你不会收到任何报错数据悄悄就没更新了。你如果需要在查询后级联操作导航属性比如order.Customer.Name xxx然后保存也容易出问题因为实体是Detached状态导航属性关联没有被正确修复。另外某些情况下EF Core会抛异常比如查询实体后用context.Entry(entity).State EntityState.Modified手动修改状态会提示无法跟踪实体因为已有相同主键的实体处于Detached状态。这个我在后面的排查章节会详细说。既然提到了场景区分我干脆做一张对比表放这儿方便你贴在工位上随时看。场景默认跟踪AsNoTracking读取列表展示浪费性能不报错推荐高效读取后修改保存推荐禁止静默失效读取后级联导航属性推荐可能报错DTO投影可以无效跟踪推荐大批量导出内存爆炸风险强烈推荐需要手动Attach修改无需额外操作需谨慎处理3. 实操从基础用法到性能实测对比光说不练假把式。这一节我直接上代码带你看看AsNoTracking()最常见的几种写法、性能实测数据以及一个日常大家可能不知道的升级版API。3.1 最基础的写法一行代码带来的改变最典型的用法就是在查询链式调用的末尾加上.AsNoTracking()using var context new AppDbContext(); // 基础用法不分页地查询大量只读数据 var logs await context.SystemLogs .AsNoTracking() .Where(l l.Level Error l.CreatedAt startTime) .OrderByDescending(l l.CreatedAt) .Take(10000) .ToListAsync(); // 投影DTO的做法即使投影也推荐加 var orderSummaries await context.Orders .AsNoTracking() .Select(o new OrderSummaryDto { Id o.Id, CustomerName o.Customer.Name, TotalAmount o.TotalAmount }) .ToListAsync();看到第二段代码有人可能会问我都投影成DTO了EF Core是不是天然就不跟踪了不完全对。EF Core确实在某些情况下会自动降级为无跟踪但在很多版本里如果实体类本身带有复杂的导航属性或者使用了某些集合操作还是会存在跟踪行为的。加AsNoTracking()就是明确表态不给EF Core任何犹豫的空间。3.2 实测数据1万条记录下到底差多少去年我优化一个工单查询接口顺手留下过一组基准测试数据。测试环境是.NET 8的WebAPISQL Server数据库单表1万条记录每条记录15个字段。我用BenchmarkDotNet连续跑了三组取中位数。查询方式耗时分派内存默认跟踪185.6 ms38.2 MBAsNoTracking()72.3 ms9.6 MBAsNoTrackingWithIdentityResolution()91.4 ms15.2 MB注意最后一行它是接下来的重头戏。3.3 进阶APIAsNoTrackingWithIdentityResolution从EF Core 2.1开始微软提供了一个既能无跟踪、又能做身份解析的方法AsNoTrackingWithIdentityResolution()。什么意思呢默认的AsNoTracking()是完全不管实体身份的如果你在同一个查询里多次查到了同一个主键的实体它们会表现为两个不同实例。这在某些场景下会让你的数据看起来有重复。而AsNoTrackingWithIdentityResolution()会在无跟踪的基础上额外做一次身份解析。比如你在查询Order时Include了Customer而同一个Customer有多条订单那么这个Customer在整个结果集里只会被实体化成一次所有相关订单都引用同一个实例。这非常有用。但代价就是它需要维护一个用于身份解析的字典性能介于默认跟踪和纯无跟踪之间。根据我的实测在包含导航属性的复杂查询里这个API的效果和性能是比较均衡的。3.4 全局配置省心的同时也要谨慎如果你觉得每个查询手动加太麻烦EF Core还提供了两种全局配置方式。第一种是在OnConfiguring中设置默认行为全项目生效protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder .UseSqlServer(connectionString) .UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking); }第二种是按上下文类型配置。设置后所有查询默认为无跟踪但如果你有特殊查询需要跟踪可以在单个查询上调用.AsTracking()覆盖回来。这个设计就很灵活了。我这里要说一句真心话全局配置虽然是好但我个人在实际项目中不太建议大家无脑全局开启。因为一旦设了全局NoTracking团队新成员很容易在需要更新数据时忘了加.AsTracking()然后就是一顿排查。我更推荐的做法是保持默认的跟踪行为让开发者在写代码时有意识地选择。只有在某个项目里已经明确所有查询都是只读、写操作被隔离到了独立的DbContext实例时全局配置才是合理的。4. 从源码层面看AsNoTracking的实现差异很多.NET开发者学过源码分析但对EF Core的内部实现比较陌生。我试着用通俗的方式讲一讲让你知道那个方法调用背后到底发生了什么。4.1 状态管理器的核心数据结构EF Core的ChangeTracker里有一个核心数据结构叫IDbContextSet说白了就是一个按实体类型分开存储的字典字典的键是实体主键值。当你执行默认跟踪查询时每读取一行数据EF Core都要查一次这个字典看这个主键是不是已经存在了。这就有意思了如果你查询了一个包含1万行的表每行的主键都不同那EF Core就要做1万次字典查找并往字典里插入1万个条目。这还只是数据加载阶段。加载完成后创建快照又是一项开销——不是你把当前值的引用存一下就行而是要复制一份完整的属性值集合这个集合用于后续的原始值比较。加上AsNoTracking()后查询内部直接把后续的状态跟踪流程跳过。加载数据时不会经历字典检查、注册和快照创建这些步骤。从一个很底层的行为角度去看两种方式下的查询执行计划是有差异的因为跟踪会影响EF生成的查询。这在后续的底部优化部分已经有很多测试验证过了。4.2 不跟踪时EF Core还做了哪些优化我挑一个特别容易被忽略的点投影优化。当你用Select投影DTO且加了AsNoTracking()时EF Core会更积极地对查询进行修剪。比如你只投影了3个字段EF Core生成的SQL可能就只SELECT这3列。但在默认跟踪模式下EF Core为了保证能恢复出完整实体有时候会额外把主键或外键字段也拉出来即使你没投影它们。这就是为什么有时候你加了AsNoTracking()除了省掉跟踪开销外SQL查询本身的返回列也会变少双重收益。4.3 一个容易误会的点AsNoTracking不会影响SQL执行有朋友可能误以为加了这个方法EF Core就会生成不同的SQL去减少扫描行数好像查询引擎会知道你只读不写然后做某种特殊优化。这个理解是不对的。AsNoTracking()影响的是EF Core的客户端行为与服务端SQL执行计划基本无关。生成的SQL还是同一个查询索引使用情况也是一样的它省的是在你拿到结果之前、EF Core在客户端为你做的附加工作。搞清楚这一点你就不会指望靠它来解决慢SQL问题——慢SQL该优化索引还是得优化索引。5. 常见踩坑与排查技巧实录这一节我整理了实战中最常碰到的几个问题。每个问题我都见过不止一次有些甚至是团队老手在特定场景下也会翻车的。5.1 问题一查询后修改不生效也没有任何报错这是最常见的坑。场景是这样的你查出实体改了属性调用SaveChanges()结果数据库毫无变化。排查了半天最后发现问题出在实体是Detached状态。我自己排查这个问题时有个习惯先查context.ChangeTracker.DebugView.ShortView如果实体状态全是Detached那基本可以断定是AsNoTracking()造成的。另外要注意如果你传递的是加了AsNoTracking()的查询结果且没有重新attach那个实体是不可能被EF Core感知修改的。解决办法要么查询时不加AsNoTracking()要么在修改前先把实体附加上context.Attach(order); // 从 Detached 转成 Unchanged order.Status Shipped; // 此时属性变更会被记录 await context.SaveChangesAsync();只修改部分字段的话用Attach后手动改Property状态也行。要提醒的是Attach会把所有属性都标记为Unchanged这样EF Core就只知道你要改指定字段了。5.2 问题二实体分离后导航属性加载异常另一个容易出问题的地方是导航属性。假设你查询时不加.Include()拿到一个Order实体访问order.Customer希望懒加载出客户信息。在默认跟踪模式下只要DbContext还没销毁EF Core可以自动把关联数据补齐。但加了AsNoTracking()且没有使用显式加载时这个懒加载经常会失败。因为实体不在状态管理器里EF Core缺失了必要的上下文线索。EF Core在检测这种访问时会抛出InvalidOperationException类似Cannot access navigation property because the entity is not being tracked。解决办法查询时用Include显式加载需要的导航属性改用AsNoTrackingWithIdentityResolution()并配合Include或者不要使用懒加载直接在项目中禁止懒加载用Include控制数据粒度我个人的建议是用Include显式加载不依赖懒加载。懒加载本身对性能不友好经常会触发额外的SQL查询。5.3 问题三手动附加时出现实体状态冲突这是一个比较隐蔽的问题。你先用AsNoTracking()查了一个实体然后又用同一个DbContext执行了另一个查询恰好返回了相同主键的实体并且是默认跟踪的。此时你再调用Attach去附加第一个实体就会报错The instance of entity type Order cannot be tracked because another instance with the same key value is already being tracked。为什么会这样因为状态管理器里已经有了一个相同主键的Order你没法再附加另一个。排查时需要查看是否在同一上下文里混用了跟踪和不跟踪的实体。解决办法尽量避免在同一个DbContext中混用两种模式查询同一张表。如果确实需要可以先用context.ChangeTracker.Clear()清理当前状态再执行附加操作。通过AsNoTracking()查出来的数据如果要进行修改我建议直接另起一个新的DbContext来做写操作干净省事。5.4 排查方法论一查二测三剖面跟AsNoTracking()相关的问题我总结了一个三步排查法。第一步查代码。用CtrlF搜一遍所有ToList()、ToListAsync()、FirstOrDefault()前面的查询看有没有AsNoTracking()。列出所有在查询后又要修改实体的地方逐点排查。第二步测响应。先用Stopwatch或MiniProfiler打点把一个查询的耗时拆成SQL执行时间和客户端处理时间。如果SQL执行时间没变而总耗时多了很多那大概率是跟踪开销。你也可以用SQL Server Profiler观察一下EF Core生成的SQL确认是不是有额外的列被查了出来。第三步剖面内存。在开发环境用 dotMemory 或者 Visual Studio 的诊断工具对比加不加AsNoTracking()的内存分配情况。这一步能直观地看到快照对象占了多少往往能让你更坚定地给相应查询加上这个方法。6. 我的一些经验和思考聊了这么多最后分享一点个人经验。我这几年做过的项目里凡是用EF Core处理过大量数据的地方基本都会贯彻这个原则只读查询和无状态查询一律AsNoTracking()写操作通过独立的工作单元处理。这样做的收益不只是性能更重要的是代码意图明确——能读不能改谁也不会在列表展示场景里误写更新逻辑。还有一个小习惯如果团队里有新人我会建议他们在写查询的时候先问自己一句话这批数据查出来之后会不会调用SaveChanges() 不会就加AsNoTracking()。会就别加。这个简单的问题能避免90%的误用。另外补充一个在分页查询中的实用技巧。如果你用的是EFCore的分页扩展库EFCore.Pagination或者自己写分页逻辑在页面上展示统计数据时建议同时使用两个查询一个是总数查询Count一个是当前页数据查询带AsNoTracking()。并且可以考虑将AsNoTracking()放到查询的最前面而不是最后因为EF Core在解析表达式树时无论方法放在链式调用的哪个位置最终都会合并到查询行为中。但为了可读性我习惯放在查询开头。说到底AsNoTracking()只是EF Core性能优化的一块基石。真正优秀的设计是你在写第一行查询代码时就清楚地知道哪些数据是状态哪些数据只是快照。把这两者分清楚你的系统在数据量增长时才有足够的底气不崩盘。最后还要再提一个容易被忽略的细节。当你使用ExecuteUpdate或ExecuteDeleteEF Core 7.0执行编译后的更新/删除操作时这些命令本来就不需要通过跟踪实体来执行。如果业务场景允许直接用这些方法替代查询实体再修改保存的老套路性能会有大幅提升。它们和AsNoTracking()一起用能让你的写操作也变得更干净利落。