14

私の質問は、このSQL の操作順序に似ていますが、少しひねりがあるので、質問するのは公平だと思います。

テラデータを使用しています。そして、私は2つのテーブルを持っています: table1, table2.

table1idには列しかありません。
table2次の列があります: id、val

私は間違っているかもしれませんが、これら 2 つのステートメントは同じ結果をもたらすと思います。

ステートメント 1。

SELECT table1.id, table2.val
FROM table1
INNER  JOIN table2
ON table1.id = table2.id
WHERE table2.val<100

ステートメント 2。

SELECT table1.id, table3.val
FROM table1
INNER JOIN (
    SELECT *
    FROM table2
    WHERE val<100
)  table3
ON table1.id=table3.id


私の質問は、クエリ オプティマイザーは、最初に WHERE 句を実行し、その後ステートメント 1 で JOIN を実行するのに十分スマートで
あるかということです。テーブル 3 はステートメント 2 では実際には必要ないことを知っています。

私はSQLにかなり慣れていないので、誤解があれば教えてください。

4

4 に答える 4

6

これは、多くの事柄 (テーブル サイズ、インデックス、キーの分散など) に依存するため、実行計画を確認する必要があります。

どのデータベースかは言いませんが、いくつかの方法があります:
MySql EXPLAIN
SQL Server SET SHOWPLAN_ALL (Transact-SQL)
Oracle EXPLAIN PLAN

Teradata の Explain とは何ですか?
Teradata Visual Explain と XML プラン ロギングにより、プランをより迅速にキャプチャして比較する

于 2010-10-18T15:27:18.853 に答える
4

問題のテーブルの統計とインデックスの可用性に応じて、オプティマイザーのクエリ書き換えメカニズムは、スキャンの前Table2にレコードのスキャンを選択する場合と選択しない場合があります。val < 100Table1

特定の状況では、データの人口統計、結合、インデックス作成、および統計に基づいて、オプティマイザーがクエリ プラン内のレコードを削除する必要があると思われる場合でも削除していないことに気付く場合があります。例のような派生テーブルがある場合でも。派生テーブルに GROUP BY を配置するだけで、オプティマイザに派生テーブルを強制的に処理させることができます。次に、オプティマイザーは、例の 2 つのテーブル間の結合を解決することを検討する前に、GROUP BY 集計を解決する必要があります。

SELECT table1.id, table3.val
FROM table1
INNER JOIN (
    SELECT table2.id, tabl2.val
    FROM table2
    WHERE val<100
    GROUP BY 1,2
)  table3
ON table1.id=table3.id

これは、標準的なアプローチがコード全体でこれを実行する必要があると言っているわけではありません。これは通常、プランの早い段階で無関係なレコードを単に削除せず、さまざまな SPOOL ファイルをスキャンして持ち運ぶデータが多すぎるクエリ プランがある場合の最後の手段の 1 つです。これは、そのような状況に遭遇したときにツールキットに組み込むことができる単純な手法です。

クエリ書き換えメカニズムは、リリースごとに継続的に更新されており、その仕組みの詳細については、Teradata 13.0のSQL トランザクション処理マニュアルを参照してください。

于 2010-10-21T14:04:26.697 に答える
1

私が何かを見逃していない限り、なぜTable1が必要なのですか??

Table2 をクエリするだけ

Select id, val  
From table2  
WHERE val<100

または、table1 の行をフィルターとして使用していますか? つまり、table1 は Table2 の Id のサブセットのみを含んでいますか??

もしそうなら、これもうまくいきます... 

 Select id, val  
 From table2  
 Where val<100 
   And id In (Select id 
              From table1)

しかし、あなたの質問に答えるには、はい、クエリ オプティマイザーは、論理的な命令を物理的な結果に変換するために必要な手順を実行するための最適な順序を見つけ出すのに十分なほどインテリジェントでなければなりません。データベースが各テーブルで保持するストアド統計を使用して、ディスク IO と処理コストを最小限に抑えるために操作を実行する順序と同様に、何をすべきか (たとえば、どのタイプの結合ロジックを使用するか) を決定します。

于 2010-10-18T15:20:19.383 に答える
0

Q1。最初にWHERE句を実行し、次にステートメント1の後半でJOINを実行します。

つまり、内部結合の順序、つまりtable2 INNER JOIN table1を切り替えると、準備段階でJOIN操作の前にWHERE句を処理できると思います。ただし、元のクエリを変更しなくても、行全体をフェッチするのに結合操作のコストが高すぎると思われる場合は、オプティマイザが順序を切り替えることができるはずなので、WHEREが最初に適用されます。ただ私の推測。

Q2。ステートメント2では表3は実際には必要ないことを知ってください

Teradataは、派生テーブルが必要になるように2番目のクエリを解釈するため、テーブル3の処理に関連する操作を継続します。

于 2010-10-19T05:27:26.437 に答える