私の質問は、LINQ for SQLを使用してパフォーマンスを最適化するためのベストプラクティスは何ですか。パフォーマンスは、ユーザーインターフェイスでの応答タイムアウトです。
現在、SQL Server 2008データベースにいくつかの販売データがあり、このデータ（MAT、毎年、さまざまなセグメント、セグメントの成長、市場成長の割合、、、、）をLINQを使用してASP.NETアプリケーションのグラフに表示しています。 SQLが実行されるIquerable式を構築するため
データベースがあり、LINQを使用してすべての質問を作成し、作成されるSQLを制御できず（追跡はできますが、、、、、）、ストアドプロシージャを使用しないため、データの取得方法が難しいという課題があります。ブラックボックスのようなものです。
現在、いくつかの単体テストを実行し、アプリケーションを手動でテストし、Databasse EngineTuningAdvisorを使用して作成するインデックスなどを使用しています。
それに加えて、私は通常、大規模なデータセットで一部のシミュレートされたユーザーでSQLプロファイラーとCLRプロファイラーの両方を使用し、データコンテキストを介した長時間のクエリや長時間の呼び出しを監視します（これは複数を意味する場合があります）裏で起こっている往復）。私の個人的な好みは、デフォルトですべてのデータコンテキストで遅延ロードとオブジェクトトラッキングを無効にすることでもあるため、ほとんどの場合、複数のラウンドトリップにオプトインする必要があります。生成されるSQLに直接影響を与えることはできませんが、LoadWith / AssociateWithに注意して、ひどく大きくて非効率的な結果セットをフェッチしないようにし、高価な結合（場合によっては複数ラウンド）が多いクエリを分割することができます。 -トリップは、大きなテーブルでのモンド結合よりも安価です）。
それはすべて測定に関するものです-あなたが手に入れることができるどんなツールでも使ってください。
プロファイリング、プロファイリング、プロファイリング。:)
タイミングだけでなく、I/Oにも注意してください。I/O 集中型の頻繁に実行されるクエリは、キャッシングにより高速に実行できますが、他のクエリに使用できるリソースが少なくなるため、db サーバーの全体的なパフォーマンスに悪影響を与える可能性があります。
あなたが言うように、L2S は少しブラック ボックスになる可能性があるため、実際のユーザーがアプリを使用している間に、すべてのシナリオやプロファイルを複製する必要があります。次に、それを使用して、1) クエリを調整し、2) インデックスを追加し、3) 必要なパフォーマンスを得るために必要なその他の変更を行います。
Linq-to-SQL 用に特別に作成されたプロファイリング ツールを使用して、「ブラック ボックスを少なく」します。これにより、生成されたクエリをコード (コール スタック) に結び付けながら、実行時のプロファイリングを実行して、特定のクエリを生成できます。実行中。http://www.huagati.com/L2SProfiler/でダウンロードして、無料の試用ライセンスを取得できます。
私のプロファイラーの背景の理由は、ここでもう少し詳しく概説されています: http://huagati.blogspot.com/2009/06/profiling-linq-to-sql-applications.html
...そして、いくつかの高度なプロファイリング オプションがここでカバーされています: http://huagati.blogspot.com/2009/08/walkthrough-of-newest-filters-and.html
多数の列を持つ多数のテーブルがある場合に役立つもう 1 つの方法は、コード エディターにインデックス情報を取得することです。これは、その情報を含む xml doc-comments をエンティティ クラスとメンバー プロパティに追加することによって行われます。その情報は、VS コード エディターのツールチップに表示されます。
...そのようにして、where句などで使用される列をカバーするインデックスがある場合、クエリを入力しているときに既に確認できます。すべてを入力する必要がないように、そのためのツールも作成しました。http://www.huagati.com/dbmltools/の「ドキュメントの更新」機能を参照してください。