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 查询问题都能定位清楚。
