2

次に例を示します。

 SELECT <columns>   
 FROM (..........<subquery>..........) AS xxx  
 INNER JOIN(s) with xxx.............  
 LEFT OUTER JOIN(s) with xxx........  
 WHERE <filter conditions>

私が間違っている場合は私を訂正してください：

  1. それ<subquery>は派生テーブルですか？
  2. WHERE句が最終結果セットに適用され、最終結果に10が含まれていても、サーバーの処理がサブクエリから離れすぎていることがわかっているため、サーバーメモリに関して返されるデータが多すぎる（たとえば数百万行）場合は問題になりますか？行？
  3. （データを削減するための）内部結合がなく、外部結合のみが残っている場合、サブクエリのすべての行と結合する必要があるため、状況はさらに悪化/遅くなりますか？
  4. （2）が問題である場合、私が考える1つの解決策は、サブクエリによって返されるデータを制限することです。これにより、内部に他の結合が追加され、処理が遅くなります（私はそれを試しました）。これについて他に何か考えはありますか？
  5. where句はサブクエリ後の結合に依存しているため、サブクエリの結果を制限できない場合はどうなりますか？
  6. 明確にするために、サブクエリが大量のデータを返す理由は、UNION ALL（フィルタリング条件なし）を使用して複数のテーブルからのデータを結合しようとしているためです。次に、サブクエリによって返された各行について、結合して情報を取得します。 WHERE句で使用する必要があります。これを行う別の方法は、サブクエリの内側から各UNION ALLのサブクエリの外側に表示されるすべての結合を実行することです。これにより、結果セットは制限されますが、結合が増えるため、処理速度が低下します。言い換えると、これを行うサブクエリから選択する必要があります。
 (
 SELECT * FROM A UNION ALL
 SELECT * FROM B UNION ALL
 SELECT * FROM C...
 ) AS xxx
 left outer join T with xxx

と

 SELECT * FROM A
 LEFT OUTER JOIN T ...
 WHERE....
 UNION ALL
 SELECT * FROM B
 LEFT OUTER JOIN T ...
 WHERE....
 UNION ALL
 SELECT * FROM C
 LEFT OUTER JOIN T ...
 WHERE....
4

1 に答える 1

2
  1. はい、そうです。
  2. いいえ、クエリ オプティマイザはクエリ全体を 1 つのブロックとして扱います。派生テーブルを実行せず、結果に対して外側のステートメントを実行します。派生テーブルを「最適化」します。
  3. 繰り返しますが、いいえ。派生テーブルがあるからといって、パフォーマンスが低下するわけではありません。常にクエリ全体を確認する必要があります。
  4. 問題じゃない。
  5. それならそれでいい。クエリ オプティマイザーを信頼してください。それを書いた人に会ったことがありますか？彼らは恐ろしく知的です。

個々のケースで、クエリ実行プランを調べて問題点を見つけることは価値があります。シークを実行している可能性があるときにスキャンを実行しているものを探します。これにより、通常、大幅なブーストが得られます。次の場合、物事はスキャンを行い、シークは行いません。

  • シークするインデックスがありません
  • あなたが求めているのは、関数の結果です (例: WHERE function(field) = value)
  • オプティマイザは、スキャンの方が実際には高速であると判断します。

しかし、質問に対する最終的な答えは - いいえ、派生テーブルを単独で選択した場合、派生テーブルに大量のデータが含まれることを心配する必要はありません。

于 2012-12-10T14:02:24.413 に答える