EF Core 慢查询排查实战：TagWith、OpenTelemetry、执行计划，30 分钟定位性能瓶颈
很多小D、小W同学都经历过这种现场：
- 压测数据很好看
- 数据库 CPU 没打满
- 业务代码看起来也没什么大问题
你改了几个Include，可能短期有效，但过两周又抖回来。根因往往不是某一行 LINQ 写错，而是整条排查链路没打通。
这篇文章就做一件事：给你一套能线上落地的 EF Core 慢查询定位闭环，从应用日志一路追到数据库执行计划，不靠猜。
问题背景：为什么本地快、线上慢
真实场景：订单列表接口平时 80ms 左右，高峰时段 P95 抬到 1s。你的第一反应是“数据库是不是扛不住了”，但监控显示：
- 数据库 CPU 长期低于 50%
- 连接池没有打满
- 磁盘 IO 没明显异常
排查下来，又遇到两个组合问题：
- 列表查询没有打 SQL 标签，日志里几百条 SQL 根本分不出谁是谁
- 某些筛选条件线上本地索引匹配不同，SQL 文本相同但参数分布不同，执行计划差异很大
也就是说，问题不是“不会优化 SQL”，而是“看不见慢点在哪”。
原理解析：慢查询定位为什么总是卡在一半
EF Core 的查询链路大致是：
- LINQ 表达式翻译成 SQL
- 命令发送到数据库执行
- 结果集回传并在应用层物化
很多排查第一步都把 SQL 抓出来看看，忽略了第 2、3 步的上下文信息，比如：
- 这条 SQL 是哪个接口触发的
- 这次慢是数据库执行慢，还是返回数据太大导致物化慢
- 慢的是固定 SQL，还是同模板下某些参数更慢
要拿到这些信息，最实用的组合就是：
TagWith：给 SQL 打业务标签OpenTelemetry：采集耗时、TraceId、SQL 标签并统一上报- 执行计划：确认索引命中、回表、扫描和 Key Lookup
三者合起来，才能形成可服用、可验证的排查闭环。
示例代码：从“日志能看见”到“瓶颈可复盘”
第一步：先在关键查询上打标签
public sealed record OrderListItemDto( |
long Id, |
string OrderNo, |
string CustomerName, |
decimal TotalAmount, |
DateTime CreatedAtUtc); |
public async Task<IReadOnlyList<OrderListItemDto>> QueryOrdersAsync( |
AppDbContext db, |
DateTime from, |
DateTime to, |
CancellationToken ct) |
{ |
return await db.Orders |
.TagWith("OrderListPage:v2") |
.AsNoTracking() |
.Where(x => x.CreatedAtUtc >= from && x.CreatedAtUtc < to) |
.OrderByDescending(x => x.CreatedAtUtc) |
.Take(100) |
.Select(x => new OrderListItemDto( |
x.Id, |
x.OrderNo, |
x.Customer.Name, |
x.TotalAmount, |
x.CreatedAtUtc)) |
.ToListAsync(ct); |
} |
TagWith会把注释写进 SQL。你在数据库侧和日志侧都能直接看到OrderListPage:v2，定位会快很多。
第二步：用 OpenTelemetry 采集慢 SQL 关键字段
using System.Collections.Generic; |
using System.Diagnostics; |
using System.IO; |
using System.Text.RegularExpressions; |
using OpenTelemetry; |
using OpenTelemetry.Trace; |
public sealed class EfSqlTagEnricher : BaseProcessor<Activity> |
{ |
private static readonly Regex EfTagLineRegex = |
new(@"^\s*--\s*(?<tag>.+?)\s*$", RegexOptions.Compiled); |
public override void OnEnd(Activity activity) |
{ |
if (activity.Kind != ActivityKind.Client) |
return; |
// 只处理数据库调用 Span |
var dbSystem = activity.GetTagItem("db.system")?.ToString(); |
if (string.IsNullOrWhiteSpace(dbSystem)) |
return; |
var statement = activity.GetTagItem("db.statement")?.ToString(); |
if (string.IsNullOrWhiteSpace(statement)) |
return; |
var tags = ExtractAllEfTags(statement); |
if (tags.Count == 0) |
return; |
activity.SetTag("ef.tags", string.Join(" | ", tags)); |
activity.SetTag("ef.primary_tag", tags[0]); |
} |
private static IReadOnlyList<string> ExtractAllEfTags(string sql) |
{ |
var tags = new List<string>(); |
using var reader = new StringReader(sql); |
while (true) |
{ |
var line = reader.ReadLine(); |
if (line is null) |
break; |
var trimmed = line.Trim(); |
if (trimmed.Length == 0) |
continue; |
var match = EfTagLineRegex.Match(line); |
if (match.Success) |
{ |
var tag = match.Groups["tag"].Value.Trim(); |
if (!string.IsNullOrWhiteSpace(tag)) |
tags.Add(tag); |
continue; |
} |
// 遇到 SQL 正文后停止，避免把正文中的注释当成业务标签。 |
break; |
} |
return tags; |
} |
} |
这段代码落地后，你就有了最关键的三类信息：
- 耗时
- TraceId
- SQL 标签（来自 TagWith）
后面不管去日志平台还是数据库审计，排查效率都会提升一个量级。
第三步：注册 OTel 并打通上报链路
using OpenTelemetry.Metrics; |
using OpenTelemetry.Resources; |
using OpenTelemetry.Trace; |
const string serviceName = "efcore-sql-traces"; |
builder.Services.AddOpenTelemetry() |
.ConfigureResource(r => r.AddService(serviceName)) |
.WithTracing(tracing => |
tracing |
.AddAspNetCoreInstrumentation() |
.AddEntityFrameworkCoreInstrumentation() |
.AddSource("MySqlConnector") |
.AddProcessor<EfSqlTagEnricher>() |
.AddOtlpExporter(o => |
{ |
o.Endpoint = new Uri("http://localhost:4318/v1/traces"); |
o.Protocol = OtlpExportProtocol.HttpProtobuf; |
}) |
); |
第四步：把 SQL 拉到数据库侧看执行计划
当你在日志里找到慢 SQL 后，下一步是确认执行计划。分析问题本质，再相应的设计和实施解决方案。
总结
EF Core 慢查询排查，不能每次都盯着 LINQ 本身看。从工程实践角度来讲，我建议你把把链路打通：
- 用
TagWith把 SQL 和业务场景绑定起来 - 用
OpenTelemetry把耗时、TraceId、SQL 标签统一上报 - 用执行计划确认瓶颈到底在扫描、回表还是排序