3

以下のように、列の値をそれ自体と比較するマルチテーブルSELECTクエリがあります。

SELECT * FROM table1 t1,table2 t2
      WHERE t1.col1=t2.col1  --Different tables,So OK.
      AND t1.col1=t1.col1    --Same tables??
      AND t2.col1=t2.col1    --Same tables??

これは私には冗長に思えます。私の質問は、それらを削除するとロジック/パフォーマンスに影響がありますか？

前もって感謝します。

4

3 に答える 3

10

これは冗長なようです。その唯一の効果は、これらの列にNULL値がある行を削除することです。これらの句を削除する前に、列がNULLでないことを確認してください。

列がnull許容の場合は、これらの行を次のように安全に置き換えることができます（読みやすく、保守しやすい）。

  AND t1.col1 IS NOT NULL
  AND t2.col1 IS NOT NULL

ジェフリーのコメントに続いて更新

あなたは絶対に正しいです、私はそれを自分でどのように見なかったかわかりません：結合条件t1.col1=t2.col1は、結合列がnullではない行のみが考慮されることを意味します。したがって、条項tx.col1=tx.col1は完全に冗長であり、安全に削除できます。

于 2010-06-29T08:02:37.760 に答える
0

影響を理解するまで、それらを削除しないでください。他の人が指摘しているように、クエリに影響がなく、おそらく最適化されている場合は、そのままにしておいても害はありませんが、削除しても害がある可能性があります。

他の何かを壊していないことを確認するまで、機能しているものを修正しようとしないでください。

私がこれに言及する理由は、次のように、まさにこの構造を持つレガシーレポートアプリケーションを継承したためです。

where id = id

そして、賢明な仲間である私はそれを捨てましたが、クエリを使用しているのはデータベースエンジンだけではないことを発見しました。

where最初に、句に存在するすべての列を抽出し、それらがインデックス付けされていることを確認するプリプロセッサを通過しました。基本的に自動調整データベース。

さて、ユーザーがフィールドでアドホッククエリを実行しているときにデータベースが以前の速度の何分の1かに減速したときの次の反復での驚きを想像してみてくださいid:-)

これは、以前のサポートチームが、一般的なアドホッククエリでもインデックス付きの列を使用していることを確認するための手抜きでしたが、標準のクエリでは使用していませんでした。

だから、私はあなたがそれをすることができないと言っているのではなく、それが最初に入れられた理由を理解するのは良い考えかもしれないことを示唆しているだけです。

于 2010-06-29T08:19:51.743 に答える
0

  1. はい、条件は同じであるため、明らかに冗長です。

    SELECT * FROM table1 t1,table2 t2
WHERE t1.col1=t2.col1

  2. ただし、少なくとも1つは必要です。それ以外の場合は、デカルト結合が手元にあります。table1の各行は、table2のすべての行に結合されます。table1に100行があり、table2に1,000行がある場合、結果のクエリは100,000の結果を返します。

    SELECT * FROM table1 t1,table2 t2 --warning!
于 2010-06-29T12:02:15.327 に答える