EF Core 本身不直接“跟踪 SQL 性能”，但提供了多种内置和扩展机制，帮助你捕获、分析和诊断 SQL 查询的执行情况。关键不是看“SQL 是否跑出来了”，而是看它是否高效、是否必要、是否被重复执行。
启用日志输出查看实际 SQL
最基础也最常用的方式是开启 EF Core 的日志功能，把生成的 SQL 打印到控制台或文件：
在 DbContext 配置中添加日志工厂（如控制台）：optionsBuilder.UseLoggerFactory(LoggerFactory.Create(b => b.AddConsole())); 运行时就能看到每条 LINQ 查询翻译成的 SQL、参数值、执行耗时（启用
DiagnosticSource或使用
Microsoft.Extensions.Logging.Console的详细级别） 注意：生产环境建议关闭或只记录 Warn/Warning 级别，避免性能干扰
用 ToQueryString 快速预览 SQL
无需真正执行查询，就能拿到 EF Core 翻译出的 SQL 字符串，适合调试和检查投影、过滤逻辑是否合理：
var sql = context.Orders.Where(o => o.Total > 100).ToQueryString(); 适用于验证Include是否导致 N+1、
Select投影是否精简、
AsSplitQuery是否生效等 注意：它返回的是“准备执行”的 SQL，不含运行时参数值，也不反映实际执行计划
集成诊断监听器抓取完整执行上下文
想获取更底层信息——比如真实执行时间、影响行数、连接打开/关闭、事务行为——需订阅 EF Core 的诊断事件：
监听Microsoft.EntityFrameworkCore.Database.Command.CommandExecuting和
CommandExecuted事件 可提取命令文本、参数、执行耗时（
event.Duration）、是否成功、是否超时等 配合
DiagnosticListener.AllListeners.Subscribe(...)实现全局监控，适合封装成性能埋点模块
结合数据库原生工具做深度分析
EF Core 日志只是起点。真正定位慢查询，必须联动数据库端工具：
SQL Server：用 SQL Server Profiler 或扩展事件（XEvent）捕获实际执行计划、CPU/IO 开销、等待类型 PostgreSQL：启用log_min_duration_statement+
pg_stat_statements查看高频/高耗时语句 MySQL：开启慢查询日志（slow_query_log），配合
EXPLAIN ANALYZE看执行路径 重点看：是否走索引、是否存在全表扫描、JOIN 顺序是否合理、临时表/排序是否过多
基本上就这些。不需要装第三方 APM 就能起步，关键是把日志、
ToQueryString、诊断事件和数据库原生分析串起来用。不复杂但容易忽略。
