EF Core 查询慢的关键在于可视化执行过程:启用 Microsoft.EntityFrameworkCore.Database.Command 日志查看 SQL 及参数,用数据库工具分析执行计划,检查 N+1 和笛卡尔爆炸,关闭懒加载暴露隐式查询,对比 AsNoTracking() 与跟踪查询差异。

EF Core 查询慢,往往不是代码写得不对,而是你不知道它到底执行了什么 SQL、发了多少次请求、有没有重复加载。调试的关键不是猜,是看见——看见生成的 SQL、看见执行次数、看见数据怎么来的。
这是最直接、最有效的第一步。EF Core 默认不输出 SQL,必须显式启用日志记录。
Microsoft.EntityFrameworkCore.Database.Command 的日志为 Information 或更高级别SELECT *、没走索引的 WHERE 条件、或嵌套子查询过多光看日志不够,要真正跑一遍。
Include 生成的 JOIN —— 如果返回几百行但实际只想要几十个主实体,大概率是笛卡尔爆炸N+1 问题肉眼难辨,但有迹可循。
entity.NavigationProperty(比如 blog.Posts.Count)且没提前 Include,就会逐条查SELECT ... WHERE Id = ?
UseLazyLoadingProxies(false))可强制暴露这类问题,避免“看起来能跑,其实很慢”有时候慢不是 SQL 慢,而是 EF Core 自身开销大。
AsNoTracking() 和默认查询的耗时与内存占用——如果差异显著,说明变更跟踪成了瓶颈.ToList() 前后的时间:如果大部分耗时在 ToList() 之后,说明反序列化或对象映射阶段压力大(比如字段太多、深嵌套)基本上就这些。不需要装插件、也不依赖第三方库,靠日志 + 执行计划 + 逻辑检查,90% 的 EF Core 查询问题都能定位清楚。
以上就是EF Core怎么调试查询问题 EF Core调试技巧与方法的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号