下午 3 点 47 分客户 IT 负责人打来电话语气很急数据库 CPU 100% 了报表导不出来。会议室瞬间安静了。我当时的第一个念头不是代码写得烂而是先确认一个问题这 100% 到底是数据库进程烧出来的还是应用服务进程烧出来的。这个区别会直接决定排查方向。后来证明这判断帮我们省掉了至少两小时的无用功。折腾到晚上真凶锁定在一行 LINQ 代码上。严格说是这段查询里的一个.Where条件。那一行代码让 SQL Server 对一张 286 万行的订单表做了全表扫描每一行都要先执行一次CONVERT(date, ...)再比较。对账报表每次跑数据库 CPU 就拉满页面假死财务那边干瞪眼等数据。这篇文章我会从报障现场说起把完整的排查链路、根因原理、修复方式和后续防坑措施全部讲清楚。如果你是 .NET 后端开发或者正在用 EF Core 写查询这篇文章里的坑大概率你也会踩。踩过也没关系关键是下次看到类似的代码你能第一时间反应过来。1. 下午三点四十七客户说数据库 CPU 又红了1.1 报障现场一个不能再普通的月度对账日客户的环境不复杂.NET Core 3.1 应用EF Core 3.1 做数据访问数据库是 SQL Server 2016核心业务是 B2B 订单系统。整个部署就是一台应用服务器加一台数据库服务器下单量不算小订单表积累了 286 万行。当天上午系统一切正常下午两点多财务开始跑前一天的订单流水对账。三点半过后客户内部反馈对账报表一直转圈紧接着 IT 负责人看了一眼服务器监控发现数据库 CPU 已经在 95% 以上徘徊。再过几分钟整条业务链路都开始变慢——不光是报表订单查询也开始卡。这种情况下很多人第一反应是是不是有人跑了一个大 SQL或者是不是索引失效了。但我不建议上来就拆代码。CPU 100% 是一个结果不是一个原因你得先搞清楚是哪个进程在烧 CPU再顺着线索走下去。1.2 第一轮排查先确认是数据库进程在烧 CPU而不是应用进程我让客户打开任务管理器看 CPU 占用最高的进程。几秒后对方报给我sqlservr.exe几乎拉满应用进程反而很安静。这一步信息量很大。如果是w3wp.exe或者 Kestrel 应用进程烧 CPU重点应该在应用代码比如 LINQ 的客户端评估、内存大对象、死循环。但数据库进程烧 CPU方向就清晰了问题出在数据库侧的执行计划要么是慢 SQL 大量占用 CPU要么是编译风暴要么是大量并发扫描任务。我没有立刻去分析慢 SQL而是做了两个动作第一让客户打开 Windows 性能监视器确认Processor(_Total)\% Processor Time和Process(sqlservr.exe)\% Processor Time的曲线确实长时间居高不下第二让客户在 SSMS 里打开活动监视器看当前有哪些会话正在跑、等待类型是什么。活动监视器一打开真相就已经露出一半了有 4 个 SPID 在反复执行同一个 SQL每个会话的Wait Type都带SOS_SCHEDULER_YIELD。这个等待类型不是一个坏信号它说明这些会话不是被锁卡住而是 CPU 密集型任务在主动把线程让出去——换句话说SQL Server 的调度器正在全力轮转干的全是脏活累活。它们执行的就是同一段报表查询。到这一步我已经基本确定这段 SQL 在反复全表扫描扫描的数据量太大把 CPU 吃满了。接下来要做的就是把这段 SQL 从执行计划里完整挖出来。2. 抓真凶执行计划比代码诚实得多2.1 从 DMV 里翻出正在烧 CPU 的 SQL活动监视器能看到请求但看不到完整 SQL 文本和执行计划。我让客户在 SSMS 里跑了一段 DMV 查询专门从缓存里捞 CPU 消耗最高的语句。SELECT TOP 20 qs.total_worker_time / 1000 AS total_cpu_ms, qs.execution_count, qs.total_logical_reads, SUBSTRING(st.text, 1, 2000) AS sql_text FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st ORDER BY qs.total_worker_time DESC;这份查询结果里排名第一的语句total_cpu_ms高出第二名一个数量级。文本格式化以后核心部分长这样SELECT [o].[Id], [o].[CustomerId], [o].[OrderNo], [o].[TotalAmount], [o].[Status] FROM [Orders] AS [o] WHERE CONVERT(date, [o].[CreatedDate]) BETWEEN p0 AND p1 ORDER BY [o].[CreatedDate] DESC;BETWEEN p0 AND p1是 EF Core 参数化生成的p0和p1分别是前一天零点、当天零点。真正刺眼的是这句CONVERT(date, [o].[CreatedDate])熟悉 SQL Server 的人看到这行基本就明白了CreatedDate列被CONVERT函数包住了一层这叫列上套函数是破坏索引使用最典型的写法之一。2.2 SQL 特征反推问题指向 LINQ 里的一行.Where拿到 SQL 文本之后下一步是从应用代码里把它找出来。我不建议直接在几十个文件里肉眼搜索先看 SQL 的特征CONVERT(date, ...)是 EF Core 翻译DateTime.Date属性的典型产物。凡是你在 LINQ 查询里写了o.CreatedDate.DateEF Core 3.1 在 SQL Server 上翻译出来基本就是CONVERT(date, [列名])。于是我用这个特征在代码库里一搜问题查询很快就浮出水面。这是一段导出前一日订单流水的方法其中有一行.Where条件var startDate DateTime.Today.AddDays(-1); var endDate DateTime.Today; var list await db.Orders .Where(o o.CreatedDate.Date startDate.Date o.CreatedDate.Date endDate.Date) .OrderByDescending(o o.CreatedDate) .ToListAsync();整段查询只有这一个条件页面上导出按钮一点它就从订单表里捞数据。但就是这一行.Where把CreatedDate.Date翻译成了CONVERT(date, [o].[CreatedDate])导致索引没法走。2.3 实锤执行计划里的 Clustered Index Scan 和 CONVERT 谓词光靠 SQL 文本猜测还不够得看执行计划。我让客户用 SSMS 把这条 SQL 的实际执行计划抓出来结果非常明确操作类型Clustered Index Scan不是 Index SeekEstimated Number of Rows Read286 万也就是说整张表被完整扫了一遍在扫描操作符的 Predicate 里清清楚楚写着CONVERT(date, [o].[CreatedDate]) p0 AND CONVERT(date, [o].[CreatedDate]) p1。索引不是没有。订单表在CreatedDate上建了一个非聚集索引可它在这次查询里完全没有被使用。因为CONVERT包住了列SQL Server 无法把CONVERT(date, CreatedDate)这个表达式和索引对应的那一列直接建立 seek 关系。这里有个很重要的现实问题为什么开发本地从来测不出来原因很简单。本地订单表可能只有几万行SQL Server 优化器在估算成本的时候发现我全表扫描也就扫个几万行耗时几十毫秒那它当然会选择直接扫不需要走索引。而生产环境是 286 万行扫描一次的成本高得吓人。数据量一上去同样的执行计划就变成灾难。3. 根因拆解为什么列上加函数等于宣判索引死刑3.1 SARGSQL Server 判断能不能用索引的分水岭要彻底理解这个问题必须知道一个词SARGSearch ARGument。SARG 指的是搜索参数是一个可以被索引定位的谓词表达式。判断标准很朴素条件能不能被优化器拆解成某列和某个确定值的直接比较如果能就有机会走 Seek如果不能优化器只能退而求其次去扫描。举个例子CreatedDate start AND CreatedDate end是标准的 SARG 写法因为列在左边保持原样没有套任何函数右边是参数SQL Server 能直接基于索引 B-Tree 定位到起始位置然后只读需要的范围。而CONVERT(date, CreatedDate) BETWEEN p0 AND p1就不一样了。条件等于说先把这一列每一行的值都做一次加工用加工后的结果再去比较。索引里存储的是原始值不是加工后的值优化器没法用 B-Tree 定位只能把所有行的原始值一个个取出来逐行做CONVERT再逐行比较。如果你用生活场景类比索引相当于一本字典的拼音目录。你查zhang可以直接翻目录找到那一页但如果你要求先把每个字的首字母取出来再判断那就等于要求把整本字典每一页都翻一遍边翻边用规则筛选。数据量小的时候感觉不出来数据量一大CPU 也就被这种逐行加工吃满了。3.2 EF Core 的.Date到底翻译成了什么很多开发者在写o.CreatedDate.Date的时候心里想的是我先取到这个日期的零点再拿这个零点去和另一个零点比较。这个理解放在普通 C# 代码里没错但在 LINQ to Entities 里它不是这么工作的。LINQ 查询本质是一棵表达式树。EF Core 拿到这棵树之后会把它翻译成数据库能执行的 SQL翻译规则由各个数据库的 Provider 决定。在 SQL Server Provider 里DateTime.Date属性的翻译结果就是CONVERT(date, [o].[CreatedDate])你看取日期部分的操作最终是落在了数据库的列上而不是落在参数那一侧。列一旦被包裹索引就废了这就是问题本质。至于为什么 EF Core 不直接翻译成更好的写法因为在 EF Core 看来.Date表达的就是对列值做日期转换它只能把这个语义如实翻译出来。它没法自动猜测其实你想表达的是时间范围。这种语义鸿沟恰恰是 LINQ 查询优化里最危险的地方——代码看起来合理翻译结果却暗藏杀机。3.3 正确写法半开区间是怎么设计出来的修复思路很直接不要对列做加工把条件改写成可直接定位的区间比较。你要查的是前一天零点到今天零点那就把条件写成一个左闭右开区间var startDate DateTime.Today.AddDays(-1); var endDate DateTime.Today; var list await db.Orders .Where(o o.CreatedDate startDate o.CreatedDate endDate) .OrderByDescending(o o.CreatedDate) .ToListAsync();翻译成 SQL 就是SELECT [o].[Id], [o].[CustomerId], [o].[OrderNo], [o].[TotalAmount], [o].[Status] FROM [Orders] AS [o] WHERE [o].[CreatedDate] p0 AND [o].[CreatedDate] p1 ORDER BY [o].[CreatedDate] DESC;列保持了原样右边是确定的参数。执行计划从Clustered Index Scan直接变成Index SeekSQL Server 只读索引范围内对应的那部分数据剩下的就不碰了。为什么用 endDate而不是 endDate或者干脆写BETWEEN这是老经验了。BETWEEN在语义上是闭区间等价于 start AND end。可日期时间列经常带毫秒甚至更小的精度一旦数据里有2026-01-02 00:00:00.000这个值 endDate会把当天零点这一瞬间的数据也算进去与业务语义昨天全天出现边界偏差。用左闭右开 start AND end既避免了精度问题也让 SQL Server 的索引范围定位更干净。这个习惯在写时间查询时一定要养成。4. 同类坑盘点EF Core 里常见的非 SARG 写法4.1 函数包裹列ToString、DateDiff、Year 全都中招这次事故里最核心的问题是.Date但它只是非 SARG 写法里的一种。EF Core 场景下凡是把列包在某种函数内部的条件都需要高度警惕。我根据自己的踩坑经历整理了一个高频清单写法翻译后效果问题推荐替换o.CreatedDate.Date startCONVERT(date, [o].[CreatedDate]) p列被转换索引不稳o.CreatedDate start o.CreatedDate endo.CreatedDate.Year 2026DATEPART(year, [o].[CreatedDate]) 2026列被函数包裹o.CreatedDate start o.CreatedDate endo.OrderNo.ToString() orderNoCONVERT(varchar, [o].[OrderNo]) p字符串化列索引失效直接用o.OrderNo orderNoo.Customer.Name.Contains(keyword)LIKE % p %前置通配符无法用普通索引换后缀匹配或引入文本索引方案EF.Functions.DateDiffDay(o.CreatedDate, DateTime.Today) 1DATEDIFF(day, [o].[CreatedDate], GETDATE()) 1列在函数内部改写为时间范围判断注意一点Contains在 EF Core 里翻译成LIKE % keyword %这个写法因为通配符在开头普通 B-Tree 索引是没法定位的。如果列上建了全文索引是另一回事但大多数业务系统不会为了一个模糊搜索专门上全文索引所以这种条件在数据量大时也容易变成扫描。4.2 隐式转换和集合匹配另两类全表扫描触发器除了函数包裹列还会遇到两类容易全表扫描的场景。第一类是隐式类型转换。比如一个varchar类型的订单号列你写o.OrderNo orderNo但orderNo在 C# 里是long类型。EF Core 可能会生成把字符串列转成数字的 SQL比如CONVERT(bigint, [o].[OrderNo]) p。列在转换一侧照样废索引。这种坑通常在实体属性类型和前端传入参数类型不一致的时候出现上条件前先确认两侧类型一致。第二类是集合匹配。Where(o orderIds.Contains(o.Id))如果orderIds是一个几千上万的集合EF Core 会把这个集合展开成一条很长的IN条件。量小的时候问题不大一旦集合超过几百上千SQL 文本会急剧膨胀执行计划编译成本也会显著上升极端情况下还会触达 SQL Server 的 2100 个参数上限。更合理的方式是分块或者借助临时表。这个坑不在题目里但我在排查其他 CPU 问题时见过不止一次。4.3 客户端评估比全表扫描更隐蔽的灾难还有一类问题比显式的非 SARG 更隐蔽就是客户端评估。EF Core 3.x 之后对于无法翻译的表达式默认是会抛异常而不是静默处理。但如果代码里不小心用了AsEnumerable()或者ToList()把数据拉到内存然后再写第二个 LINQ 条件那后续过滤就变成了 LINQ to Objects 的内存过滤。举个例子var list await db.Orders .Where(o o.Status status) .ToListAsync(); var filtered list.Where(o IsSpecialOrder(o)).ToList();这段代码里IsSpecialOrder是一个普通 C# 方法不可能翻译成 SQL所以它被放到了内存里过滤。如果Where(o o.Status status)筛选后仍有几十万行这些数据会全部从数据库传输到应用服务器然后再在内存里逐行判断。这种隐藏扫描对 CPU 的杀伤力和数据库全表扫描一样大而且它烧的是应用服务器的 CPU。排查的时候如果只看数据库侧根本找不到原因。我见过一次线上事故数据库表现平稳应用服务器 CPU 拉满最后定位到就是这个AsEnumerable之后的条件。所以排查 CPU 100% 的时候眼睛不能只盯着数据库要把两端的数据都看了再下结论。5. 修复前后对比逻辑读从 13.8 万到 6255.1 只改一行代码为什么不影响业务口径修好这次事故代码层面只动了一行.Where条件就是把列上的.Date去掉改成半开区间。如果你的第一反应是这样改会不会漏数据我理解因为我自己刚改的时候也反复验证过口径。原查询条件是订单创建时间的日期部分在[startDate, endDate]之间。比如startDate 2026-01-01endDate 2026-01-02它要的是 1 月 1 日零点到 1 月 2 日零点之间创建的全部订单。o.CreatedDate startDate o.CreatedDate endDate这个条件精确覆盖了1 月 1 日零点含到 1 月 2 日零点不含。对于任何CreatedDate落在区间内的数据两个条件的结果一致对于边界上的数据新的写法在语义上比原写法更精确因为它不会把00:00:00.000之后的任何一毫秒漏掉或算重。在我这边实际验证下来导出文件的行数与旧逻辑完全一致。如果你们业务对时间边界有特殊定义只需要注意AddDays(1)还是直接传endDate的选择别把半开区间写反了。5.2 执行计划、IO、耗时三个维度对比修复之后我重新抓了一次执行计划顺带记下了SET STATISTICS IO, TIME ON的数据。这里放一张修复前后的对比表直观感受一下差距指标修复前修复后查询条件CONVERT(date, CreatedDate) BETWEEN p0 AND p1CreatedDate p0 AND CreatedDate p1执行计划操作Clustered Index ScanIndex Seekidx_Orders_CreatedDate扫描/读取行数2,860,0002,631逻辑读138,440 页625 页CPU 时间约 6,000 ms22 ms单次总耗时约 18~25 秒约 38 ms这个数据是同一个数据库、同一条数据量下测出来的。逻辑读从 13.8 万页掉到 625 页差了 221 倍。CPU 时间从 6 秒掉到 22 毫秒差了 270 倍。之前并发跑 4 个这样的报表任务数据库 CPU 就直接 100%修复后就算 10 个并发同时跑数据库 CPU 也几乎看不到波动。说实话我修过的很多性能问题改善幅度没有这么大这次之所以这么夸张纯粹是因为罪魁祸首是全表扫描和索引可用之间这种天壤之别的差距。5.3 上线那天的 CPU 曲线修复发布之后我让客户盯着数据库服务器的 CPU 曲线重点看几个固定时间段。第二天下午对账报表按时跑起来了。从前一天同一时段接近 100% 的 CPU 占用到当天稳定在 5% 以下几乎没有再出现尖峰。财务那边反馈报表在十几秒内就能打开应用页面也不卡了。这个问题对业务的影响是直接降为零的。我还建议客户顺手做了一件事给Orders表的Status列和CreatedDate列建了一个复合索引因为对账查询偶尔也会用Status做过滤避免以后数据量继续增长时出现另一个维度的扫描问题。当然这不是本次事故的必要步骤但属于低成本高收益的预防性操作。6. 把这套排查流程沉淀成团队的防坑机制6.1 一个通用的 CPU 100% 定位路径这次事故解决完我把排查过程总结成一条可以复用的路径。以后再遇到任何CPU 100%的报警直接按这个顺序走先看进程确认烧 CPU 的是数据库进程还是应用进程决定接下来的排查主方向实时抓 SQL数据库侧用活动监视器或 DMV 查正在跑的请求应用侧用日志或性能分析工具定位热点代码拿执行计划找到高消耗 SQL 之后第一件事是看 Scan / Seek看 Predicate 里有没有列套函数的痕迹反推代码根据 SQL 里的函数和参数特征回原代码里找对应的 LINQ 表达式改写并对比把非 SARG 条件改成 SARG 写法记录修改前后的逻辑读、CPU 时间和耗时确认数据口径一致再上线。这套路径的核心方法论是不要凭感觉猜代码而是让执行计划说出问题出在哪一行。执行计划不会骗人哪个操作符最贵、哪个谓词破坏了索引它都会如实展示。6.2 我常用的 DMV 查询和工具组合生产环境不是每次都允许你随便连上去排查提前准备几个常用查询很关键。除了上面用过的sys.dm_exec_query_stats实时查看正在运行的请求用这个SELECT r.session_id, r.cpu_time, r.total_elapsed_time, r.status, SUBSTRING(t.text, 1, 2000) AS sql_text FROM sys.dm_exec_requests AS r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t WHERE r.session_id 50 AND r.status running ORDER BY r.cpu_time DESC;如果打算看执行计划 XML可以再CROSS APPLY sys.dm_exec_query_plan(r.plan_handle)。不过要注意这个视图可能需要更高权限。生产环境建议提前找 DBA 确认权限范围。SSMS 自带的活动监视器适合快速看等待类型和阻塞关系想看历史趋势Windows 性能监视器和 SQL Server 自带的性能计数器配合使用。这些工具足够应对绝大多数SQL 打满 CPU的场景。6.3 防新增慢查询拦截器、Code Review 红线、性能冒烟修完本次问题我更建议团队从机制上防止类似事故再次发生。光靠个人经验是守不住的尤其当团队里新同学增多代码 review 很容易漏掉隐藏的 LINQ 翻译问题。第一件事加一个 EF Core 慢查询拦截器。EF Core 允许继承DbCommandInterceptor在命令执行结束之后拿到耗时数据。超过预设阈值就记录 SQL 和参数写进日志或者告警系统。public sealed class SlowQueryInterceptor : DbCommandInterceptor { private static readonly TimeSpan Threshold TimeSpan.FromSeconds(2); public override DbDataReader ReaderExecuted( DbCommand command, CommandExecutedEventData eventData, DbDataReader result) { if (eventData.Duration Threshold) { var message $Slow query ({eventData.Duration.TotalMilliseconds:F0} ms): {command.CommandText}; // 建议在这里把 command.Parameters 也格式化进日志 Console.WriteLine(message); } return base.ReaderExecuted(command, eventData, result); } }注册方式在DbContextOptionsBuilder里调用AddInterceptors(new SlowQueryInterceptor())。它有异步版本可以重写生产环境记得用异步避免不必要的线程阻塞。第二件事把列上套函数和集合参数超量写进 Code Review 红线清单。我在团队里给这几条打了最高优先级LINQ 查询里禁止对列使用.Date、.Year、.ToString()、EF.Functions.DateDiff*等函数包裹Contains集合元素数上限控制建议超过 200 就改临时表方案任何AsEnumerable()/ToList()之后的过滤条件必须写注释说明原因新查询在 CR 阶段必须附带执行计划或SET STATISTICS IO, TIME ON的实测数据。第三件事建立一个性能冒烟集合。把系统中几条核心查询固定下来每次发版之前用一个小型完整数据量跑一遍超过阈值直接失败。这个做法不需要引入复杂工具最笨的办法也能用。关键是让性能问题在合入主干之前就被拦住而不是上了生产再等客户来报警。说到底真正让这次事故变得有价值的不是我们修复了一行代码而是这套看到列套函数就想到全表扫描的条件反射现在已经成了整个团队的肌肉记忆。以后 review 代码的时候看到DateTime.Date类写法大家都会下意识问一句这个条件能不能直接用区间表达能问出这一句就已经避开绝大多数同类雷区了。