5

LINQ クエリとその実行計画のプロファイリングは、作成されることがあるクレイジーな SQL のため、特に重要です。

特定のクエリを追跡する必要があり、クエリ アナライザーで見つけるのに苦労することがよくあります。多くの場合、実行中のトランザクションが多いデータベース (運用サーバーの場合もあります) でこれを行うことが多いため、プロファイラーを開くだけでは不十分です。

また、DataContext を使用して不十分なトレースをしようとしていることがわかりました。これは、実際に自分で実行できる SQL が得られないためです。

これまでのところ、私の最善の戦略は、クエリに「乱数」を追加し、トレースでそれをフィルタリングすることです。

リンク:

where o.CompletedOrderID != "59872547981"

プロファイラー フィルター:

'TextData' like '%59872547981'

これは、いくつかの注意事項がありますが、正常に機能します。

  • 条件を削除するか、クエリ プランにあまり影響を与えないものを選択するように注意する必要があります。はい、そのままにしておくと問題が発生することはわかっています。
  • 私が知る限り、このアプローチを使用しても、追跡する必要があるすべての LINQ クエリに対して新しいトレースを開始する必要があります。既存のトレースの [ファイル] > [プロパティ] に移動すると、フィルター条件を変更できません。

アプリでクエリを実行し、それがプロファイラーにポップアップ表示されるのを見るのに勝るものはありません。他の誰かがこれよりも良い方法を思いついたか、少なくとも列のクエリよりも「危険な」トークンを検索することを提案したかっただけです。

4

4 に答える 4

5

where句をいじることは、クエリの実行計画に影響を与える可能性があるため、最善の方法ではない可能性があります。

代わりに、匿名クラスへの射影で何かファンキーなことをしてください - 一意の静的列名または実行計画に影響を与えない何かを使用してください。（そうすれば、後で本番コードのプロファイリングを行う必要がある場合に備えて、本番コードにそのまま残すことができます...）

from someobject in dc.SomeTable
where someobject.xyz = 123
select new { MyObject = someobject, QueryTraceID1234132412='boo' }
于 2008-11-25T02:50:08.133 に答える
3

Linq to SQL Debug Visualiser（http://weblogs.asp.net/scottgu/archive/2007/07/31/linq-to-sql-debug-visualizer.aspx ）を使用して、ウォッチウィンドウで確認できます。

DataContext.GetCommand();または、SQLを実行する前にSQLを確認するために使用できます。

を見て、DataContext.GetChangeSet()何が挿入/更新または削除されるかを確認することもできます。

于 2008-11-25T03:38:14.293 に答える
1

データコンテキストで未加工の SQL をログに記録し、それをプロファイラーで検索してパフォーマンスを調べることができます。

using System.Diagnostics.Debugger;

yourDataContext.Log = new DebuggerWriter();

これで、すべての SQL クエリがデバッガーの出力ウィンドウに表示されます。

于 2008-11-25T02:40:12.913 に答える