私はテーブル間の多くの結合を伴う作業を行っており、サブクエリの使用は他のコマンドよりもはるかに遅いと教えられてきましたが、私が行ってきたことのいくつかでは、サブクエリを使用するか作成する必要があるようです.新しいテーブル。同じサブクエリを複数回呼び出す可能性があるため、代わりにサブクエリごとに類似のテーブルを作成し、それらを使用しています。これは効率的だと思いますか？私が別の方法で物事を行うべきかどうか教えてください。
質問する
481 次
3 に答える
3
サブクエリの使用は他のコマンドよりもはるかに遅いという包括的な声明を出すことは、まったく間違っています。いつものように、それは依存します。ここにいる誰も、あなたの質問に明確な答えを与えることはできません。しかし、これは自分で簡単に理解できるはずです。両方のアプローチを簡単に作成し、生成されたクエリ プランを SSMS で調べ、クエリ統計を Profiler で調べることができます (いずれにせよ実行する必要があります)。これにより、特定の問題に対する最適なアプローチが決定されます。
于 2012-10-09T19:06:12.587 に答える
0
この 2 つの選択肢だけに限定されるわけではありません。クエリでは、サブクエリ、CTE、一時テーブル、またはテーブル変数を使用できます。クエリの外部で、ビュー、インデックス付きビュー、またはテーブルを維持できます。どちらが最適に実行されるかは、クエリの正確な動作、ターゲット テーブル内の行数、既存のインデックス、マシンで使用可能なディスク容量/RAM の量などによって異なります。また、サブクエリを使用している場合は、サブクエリが複数回呼び出されないように、クエリ全体を作成する方法はありますか? 創造的な結合方法か何かを使用して、セットベースの操作に組み込むのでしょうか?
于 2012-10-09T19:15:26.563 に答える
0
正しい答えも間違った答えもありませんが、最も可能性の高い正しい答えは、共通テーブル式または CTE を使用することです。
心に留めておく必要がある主なことは、データの量、データの分散または統計、インデックス、サブクエリの選択性または一般性、ディスクの速度など、さまざまな要因によってパフォーマンスが大幅に変化することです。つまり、メモリに保持できるクエリの量と、他の多くのものです。
一般的に言えば、両方のクエリを作成し、最初のクエリの前に次を追加します。
SET STATISTICS IO ON
次に、バッチを実行し、ビューをデータセットを表示するのではなく「メッセージ」に切り替えます。各クエリと各テーブルで発生した「論理読み取り」が (とりわけ) 表示されます。
一般的に言えば、これらの論理読み取りを低くする必要があります。
可能であれば、ライブ データのコピーを使用してこのテストを実行してください。これにより、ライブ サーバーでこれを実行したときに何が起こるかを最も近似することができます。(SQL オプティマイザーは、レプリケーション、ユーザー アクティビティ、実行中のその他のレポートなど、一般的なサーバー負荷に合わせて最適化している可能性があるため、最も近い近似値です)
同じサブクエリを複数回呼び出すことについての説明によると、CTE が探しているものであり、これらは多くの場合、代替よりも優れたパフォーマンスを発揮します。
于 2012-10-09T22:13:19.050 に答える