EF Core 本身不直接跟踪 SQL 性能，但提供日志输出、ToQueryString、诊断监听器及数据库原生工具四类机制：启用 ILogger 查看实际 SQL 与耗时；ToQueryString 预览翻译结果；订阅 CommandExecuting/Executed 获取执行上下文；结合 SQL Server Profiler、pg_stat_statements 或 MySQL 慢日志分析执行计划与性能瓶颈。
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、诊断事件和数据库原生分析串起来用。不复杂但容易忽略。
