EF Core 如何查看实际执行的 SQL 并分析查询性能？实用调试指南

使用 ToQueryString 查看生成的 SQL

在 EF Core 开发中，LINQ 查询最终会转换成 SQL 发送给数据库。如果查询结果不符合预期，或者接口响应较慢，可以先查看 EF Core 生成的 SQL。

EF Core 提供了 ToQueryString() 方法，可以在不执行查询的情况下查看生成的 SQL。

var query = context.Users
    .Where(u => u.Age > 18)
    .OrderBy(u => u.Name)
    .Take(20);

Console.WriteLine(query.ToQueryString());

输出内容通常包含 SELECT、WHERE、ORDER BY 和分页相关语句。需要注意，ToQueryString() 主要用于调试生成的查询，不保证输出内容可以直接复制到数据库中执行，也不一定完整反映最终执行命令的参数传递方式。

使用 LogTo 输出实际执行的 SQL

如果需要查看真正发送到数据库的 SQL，以及每条命令的执行耗时，可以使用 EF Core 的 LogTo()。

在 DbContext 配置中添加：

protected override void OnConfiguring(
    DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .LogTo(Console.WriteLine,
            Microsoft.Extensions.Logging.LogLevel.Information);
}

执行查询时，控制台会输出 SQL 命令及相关日志，其中通常包含 Executed DbCommand 和耗时信息。

如果项目使用 ASP.NET Core，通常更适合通过 Microsoft.Extensions.Logging 配置日志，将数据库命令输出到控制台或现有日志系统，方便按请求追踪和筛选。

开发阶段可以临时开启敏感数据日志：

optionsBuilder.EnableSensitiveDataLogging();

这可能会输出 SQL 参数中的实际值。生产环境应谨慎启用，避免密码、个人信息等敏感数据进入日志。

如何分析 SQL 查询性能

拿到 SQL 后，不要只看语句是否复杂，还需要结合执行时间和数据库执行计划分析。

检查执行耗时。 如果一条查询持续耗时较高，先确认瓶颈来自数据库执行、网络传输还是结果集处理。日志中的命令耗时可以帮助缩小排查范围。

检查索引使用情况。 对 WHERE、JOIN 和 ORDER BY 涉及的字段，查看执行计划是否使用合适的索引。大表全表扫描、低效连接和不必要的排序都可能拖慢查询。

检查返回的数据量。 避免无必要地加载整张表。只读取需要的字段，可以使用 Select 投影到 DTO，减少数据库传输和对象创建开销。

var users = await context.Users
    .AsNoTracking()
    .Where(u => u.IsActive)
    .Select(u => new UserDto
    {
        Id = u.Id,
        Name = u.Name
    })
    .ToListAsync();

对于只读查询，AsNoTracking() 通常可以减少变更跟踪开销，但实际收益取决于查询规模和应用场景。

排查重复查询和关联查询问题

如果一次接口请求触发了大量 SQL，应检查是否存在延迟加载引发的 N+1 查询问题。例如，先查询用户列表，再在循环中逐个访问每个用户的订单，就可能额外执行许多次数据库查询。

可以结合 SQL 日志统计命令数量，并检查是否需要使用 Include、投影查询或分批读取关联数据。使用 Include 时也要留意多个集合关联可能造成结果集膨胀，必要时考虑 AsSplitQuery()。

对于 SQL Server，可以将慢查询放入 SQL Server Management Studio，查看实际执行计划，重点关注索引扫描、查找操作、连接方式和高成本算子。

总结

排查 EF Core 查询性能，可以先用 ToQueryString() 查看生成的 SQL，再通过 LogTo() 或日志系统获取实际执行命令及耗时，最后结合数据库执行计划定位瓶颈。

不要看到复杂 SQL 就直接认定 EF Core 性能差。通过检查索引、返回字段、查询次数和关联方式，通常更容易找到真正影响接口响应速度的问题。