EF Core 查询慢的关键在于可视化执行过程：启用 Microsoft.EntityFrameworkCore.Database.Command 日志查看 SQL 及参数，用数据库工具分析执行计划，检查 N+1 和笛卡尔爆炸，关闭懒加载暴露隐式查询，对比 AsNoTracking() 与跟踪查询差异。
EF Core 查询慢，往往不是代码写得不对，而是你不知道它到底执行了什么 SQL、发了多少次请求、有没有重复加载。调试的关键不是猜，是看见——看见生成的 SQL、看见执行次数、看见数据怎么来的。
打开 SQL 日志，让 EF Core “开口说话”
这是最直接、最有效的第一步。EF Core 默认不输出 SQL，必须显式启用日志记录。
- 在 Program.cs 或 Startup.cs 中配置日志级别：添加
Microsoft.EntityFrameworkCore.Database.Command的日志为Information或更高级别 - 使用内置日志提供程序（如 Console）就能实时看到每条生成的 SQL 和参数值
- 重点关注重复出现的相似语句——大概率是 N+1 查询的铁证
- 注意看是否出现
SELECT *、没走索引的WHERE条件、或嵌套子查询过多
用数据库工具验证生成的 SQL
光看日志不够，要真正跑一遍。
- 把日志里复制出的 SQL 粘贴到 SQL Server Management Studio、Azure Data Studio 或其他数据库客户端中执行
- 查看执行计划（Execution Plan），确认是否用了索引、有没有全表扫描、JOIN 是否合理
- 特别留意多层
Include生成的 JOIN —— 如果返回几百行但实际只想要几十个主实体，大概率是笛卡尔爆炸
检查导航属性访问是否触发额外查询
N+1 问题肉眼难辨，但有迹可循。
- 在循环中访问
entity.NavigationProperty（比如blog.Posts.Count）且没提前Include，就会逐条查 - 用日志观察：主查询之后是否紧跟着一串几乎一样的
SELECT ... WHERE Id = ? - 临时关闭懒加载（
UseLazyLoadingProxies(false)）可强制暴露这类问题，避免“看起来能跑，其实很慢”
用内存和时间指标辅助判断
有时候慢不是 SQL 慢，而是 EF Core 自身开销大。
- 对比
AsNoTracking()和默认查询的耗时与内存占用——如果差异显著，说明变更跟踪成了瓶颈 - 对同一查询，分别测
.ToList()前后的时间：如果大部分耗时在 ToList() 之后，说明反序列化或对象映射阶段压力大（比如字段太多、深嵌套） - 用 Visual Studio 的 Diagnostic Tools 或 dotMemory 查看 GC 频率和对象分配量，高频率小对象分配常来自未投影的实体加载
基本上就这些。不需要装插件、也不依赖第三方库，靠日志 + 执行计划 + 逻辑检查，90% 的 EF Core 查询问题都能定位清楚。
