刚好之前做过EF查询性能调优，用SQL Server Profiler踩过不少坑，来给你梳理清楚这两个问题：

一、Profiler里必须重点监控的事件（针对EF场景） #

当你用Profiler分析EF LINQ的性能时，不用盯着所有事件看，重点关注这些就够了：

• SQL:BatchCompleted 和 RPC:Completed：这俩是你已经确认的核心事件，所有实际执行的查询都会触发其中一个，是性能分析的基础
• SP:StmtCompleted：如果你的EF项目用到了存储过程映射，这个事件能帮你看透存储过程内部的具体SQL执行，精准定位存储过程里的慢查询
• Showplan XML：要是你需要分析查询的执行计划（比如排查索引缺失、全表扫描），可以临时开启这个事件获取完整的执行计划——但注意别一直开着，会给服务器加额外负载，按需启用就好
• SQL:StmtStarting/Completed：想跟踪更细粒度的SQL执行？比如EF悄悄拆分的多个小查询，这个事件能帮你把每一步都看清楚
• Deadlock Graph：如果EF查询遇到死锁问题，这个事件能捕获死锁的完整图谱，包括哪些资源在竞争、哪些进程被阻塞
• Lock:Deadlock 和 Lock:DeadlockChain：辅助排查死锁的细节事件，能帮你理清死锁发生的前后链条

二、SQL:BatchCompleted 与 RPC:Completed 的核心差异 #

这俩事件都是记录查询完成，但触发场景和细节完全不同，结合EF的使用场景给你拆解：

1. 执行方式本质不同

   • RPC:Completed：全称是Remote Procedure Call，对应EF默认的参数化查询场景。比如你写的LINQ查询，EF会自动转换成带参数的SQL，然后通过RPC调用发送给SQL Server。你在事件的TextData里能看到@p0、@p1这类参数，以及对应的参数值，这也是EF防止SQL注入、提升查询计划重用的关键方式。
   • SQL:BatchCompleted：对应批量执行的非参数化SQL或者直接发送的SQL脚本块。比如你用EF的ExecuteSqlRaw执行手动拼接的SQL字符串（不带参数），或者某些第三方批量操作扩展，就会触发这个事件。它记录的是整个SQL批次执行完成的情况。

2. EF场景下的触发频率差异

   • 绝大多数EF的常规操作（查询、增删改）都会触发RPC:Completed，因为EF默认就用参数化查询，这是最佳实践。
   • SQL:BatchCompleted在EF里属于少见情况，一般只有你主动写原生非参数化SQL才会触发。

3. 事件详情的直观区别

   • 看RPC:Completed的TextData，会是类似这样的内容：

     exec sp_executesql N'SELECT [u].[Id], [u].[Name] FROM [Users] AS [u] WHERE [u].[Id] = @p0', N'@p0 int', @p0=5
     

     明确显示是通过sp_executesql调用的参数化查询。
   • SQL:BatchCompleted的TextData则是直接的SQL语句：

     SELECT [Id], [Name] FROM [Users] WHERE [Id] = 5
     

     没有参数化的包装，直接执行。

4. 性能优化层面的区别

   • RPC对应的参数化查询能让SQL Server缓存执行计划，相同结构的查询（只是参数不同）可以重用同一个计划，减少编译开销，提升性能，这也是EF默认这么做的原因。
   • SQL:Batch对应的非参数化查询，每次执行都可能重新编译计划，不仅性能差，还存在SQL注入风险，除非特殊需求，尽量避免在EF里这么写。

内容的提问来源于stack exchange，提问作者Nipuna