3

特別な形式のequijoinを使用するこの特定のスクリプトに出くわしました。

SELECT * 
FROM 
per_assignments a, per_assigment_types b
WHERE
a.assignment_status_type_id + 0  = b.assignment_status_type_id

なぜ等結合にゼロが追加されるのですか？インデックス検索を回避することと関係があることを知りましたが、それでも誰かが同じことの全体像を説明することができます。前もって感謝します

編集 ：

これは、テーブル/列の宣言に関連するものではありません。私の知る限り、これはSQLチューニングと関係があります。

これは私が見つけたものです：-

  1. これは小さなテーブルで使用されます。
  2. 通常のようにインデックス検索を行う代わりに、これはテーブル全体を一度に検索します。

しかし、通常の等結合との違い、さらにはインデックス作成がパフォーマンスにどのように影響するかを正確に知りません。

誰かが特定の文脈の中で説明し、私の発見が間違っているかどうかを知らせてくれると本当に助かります。同じためにあなたの時間と努力に感謝します:-)

列の説明：

両方のテーブルの割り当てステータスタイプIDは、NUMBER（9）として宣言されています。

4

1 に答える 1

3

小さなテーブルのインデックスの使用を停止する理由は、パフォーマンスです。インデックスを使用して結合を実行すると、データを読み取るために 2 つのディスク I/O が必要になります。1 つはインデックスを読み取り、もう 1 つはテーブル全体からデータを読み取ります。小さなテーブルでは、2 回目のディスク I/O を実行するよりも、テーブル全体を読み取ってフル テーブル スキャンを実行する方が高速になる場合があります。

これは大まかな一般化であり、データベース内であっても時々異なる場合があります。理論的には、SQL オプティマイザーは、この条件を認識し、ヒントがなくてもインデックス ルックアップに対して完全なテーブル スキャンを使用できるほどスマートである必要があります。また、一方または両方のテーブルにデータを追加すると、全テーブル スキャンからインデックス ルックアップのパフォーマンスが向上する可能性もあります。

これらのクエリの調整について私が持っている質問は次のとおりです。

  1. VARCHAR 列 (存在する場合) が平均でどれくらいいっぱいかなど、テーブルの正確な定義は何ですか?
  2. 各テーブルには何行ありますか?
  3. 各テーブルに 1 日あたり何行追加されますか?
  4. このクエリはどのくらいの頻度で実行されますか?
  5. どちらが速いかを確認するために、両方のオプションでクエリの実行時間を測定した人はいますか?

私の懸念は、このクエリが以前のバージョンのデータベース用に巧妙なパフォーマンス強化として作成されたか、クエリ オプティマイザが同じように、またはより良い仕事をする可能性があることに気付かずに巧妙なハックとして作成されたことです。

于 2011-05-09T13:37:18.000 に答える