Question

由于有时可以创建疯狂的SQL，因此分析LINQ查询及其执行计划尤为重要。

我经常发现我需要跟踪特定查询，并且很难在查询分析器中查找。我经常在一个有很多正在运行的事务（有时是生产服务器）的数据库上这样做 - 所以只是打开Profiler是不行的。

我也发现tryin使用DataContext来追踪不足，因为它不会给我SQL我实际上可以自己执行。

到目前为止，我最好的策略是在查询中添加一个“随机”数字，并在跟踪中对其进行过滤。

LINQ：

where o.CompletedOrderID != "59872547981"

Profiler过滤器：

'TextData' like '%59872547981'

这可以很好地解决几个问题：

我必须小心记住删除标准，或选择一些不会过多影响查询计划的内容。是的，我知道留下来就是在寻找麻烦。
据我所知，即使采用这种方法，我也需要为我需要跟踪的每个LINQ查询启动一个新的跟踪。如果我去'文件＆gt;现有跟踪的属性'我无法更改过滤条件。

你无法在你的应用程序中运行查询，并且无需任何额外的努力就可以在Profiler中弹出查询。只是希望其他人提出比这更好的方法，或至少建议一个不那么“危险”的令牌来搜索而不是查询列。

Answer 1

使用where子句搞乱可能不是最好的事情，因为它可以并且会影响查询的执行计划。

通过投射到匿名类来做一些时髦的事情 - 使用唯一的静态列名或不会影响执行计划的东西。（这样你就可以在生产代码中保留它，以防你以后需要对生产代码进行任何分析......）

from someobject in dc.SomeTable
where someobject.xyz = 123
select new { MyObject = someobject, QueryTraceID1234132412='boo' }

Answer 2

您可以使用Linq to SQL Debug Visualiser - http://weblogs.asp.net/scottgu/archive/2007/07/31/linq-to-sql-debug-visualizer.aspx并在监视窗口中查看它。

或者您可以在执行之前使用DataContext.GetCommand();查看SQL。

您还可以查看DataContext.GetChangeSet()以查看要插入/更新或删除的内容。

Answer 3

您可以让您的datacontext注销原始SQL，然后您可以在分析器中搜索以检查性能。

using System.Diagnostics.Debugger;

yourDataContext.Log = new DebuggerWriter();

现在，所有SQL查询都将显示在调试器输出窗口中。

Answer 4

EFCore为此具有功能TagWith()。

 var nearestFriends =
      (from f in context.Friends.TagWith("This is my spatial query!")
      orderby f.Location.Distance(myLocation) descending
      select f).Take(5).ToList();

https://docs.microsoft.com/en-us/ef/core/querying/tags

不幸的是，您无法使用Query Store来找到它们：-）

这是因为查询前的注释为stripped out。

太可惜了！希望我不必再等12年。

在SQL事件探查器中查找特定LINQ查询的巧妙技巧

4 个答案: