トラフィックの多いWebサイトには、LINQ to SQLを使用する必要があります。

スタックオーバーフローには十分うまくいくようです;-pコンパイル済みクエリこれは、（たとえば）適切なDB設計と比較して正しい列/行をフェッチし、n + 1のロードを回避することと比較して、ボトルネックになる可能性は低いです。

• @Gravel&& @バイヤーズ。一つの質問。 3台のサーバーがあるとします。 1が読み取り用、1が書き込み用、もう1つがレプリケーションサーバーです。だから私は読み取り操作と書き込み操作のためにlinqを使うのなら私は手で問い合わせを使う。これが最善の解決策ですか？または他の最良の解決策はありますか。あなたが提案するもの - Adeel
• @アデル - DBサーバーやアプリサーバー？それはあなたがdbサーバーを意味しているように聞こえます - しかし私はそのことを確信していません特定使用されているデータアクセスAPIは、大きな違いを生むでしょう（異なるdb設定と比較して）。 - Marc Gravell♦
• あなたは常に読み込みにSP / UDFを使うこともできます（L2S経由で）... - Marc Gravell♦
• @Gravel Serverはデータベースサーバーを意味します。 linqのアプローチはデータアクセスapiと比較して書き込み操作に対して非常に遅いので、読み込みに対してはパフォーマンスオーバーヘッドはごくわずかです。それでそれはそれだけでREAD目的のためにlinqを使うほうが良いですか？ - Adeel
• @アデル - 確かにより良い書き込みより読み取り時。ただし、実際はシナリオによって異なります。ほとんどのコードは大量のDMLを発行していません。もし、あんたが行うこれを行うには、コマンドのバッチ処理が望ましいですが、データをまとめてDBに送信し（xmlやSqlBulkCopy、SQL 2008のテーブル値パラメータなど）、set-based updates / insertを使用して処理することもできます。デシベル。これらのうち最初のものだけがL2S経由で利用可能です。 - Marc Gravell♦

読み取り操作の場合、LINQ To SQLはSQLを直接書き込むのとほぼ同じくらい高速であるはずです。 SQLを作成することによるオーバーヘッドはそれほど顕著ではありません。手作業でクエリを書いた場合ほど最適ではないクエリがいくつかあるかもしれませんが、私の経験ではほとんどの場合非常にうまく機能します。

一括更新の場合、LINQ To SQLは行を一度に1つずつ処理するため、通常は遅くなります。こんなことはできませんUPDATE Foo SET x = 0 WHERE id BETWEEN 100 AND 200すべての行を取得せずにLINQ to SQLで。現時点では、この種の操作にはSQLを手で書くのが最善です。

更新と削除は、影響を受けるオブジェクトごとに別々のステートメントが生成されるため、LINQ to SQLが現在問題となっている場所です。

とは言っても、このブログ記事では、両方の操作を1つのステートメントにまとめる方法について詳しく説明しています。これは、パフォーマンスの向上に役立ちます。LINQ to SQLによるバッチ更新と削除。

特にクエリが特定の結果を得るために使用されているような場合、コンパイルされたクエリは頻繁に使用されるクエリにも役立ちます。この記事も参考になるでしょう。LINQ to SQLアプリケーションのパフォーマンスを向上させる10のヒント。