2

私は自分自身をかなり漬け込んでいることに気づきました。多かれ少なかれvarchar（25）である1つの列（抑制リストまたは包含リスト）のみのテーブルがありますが、メインクエリで使用する前にインデックスを作成する時間がないため、重要性によっては、各テーブルにいくつの行があるのか​​わかりません。これらすべての中心となるベーステーブルは、約140万行と約50列です。

私の仮定は次のとおりです。

INは、値が連続して表示されるため、多くの値（行）が返される場合には使用しないでください。（サブクエリのINは値を直接渡さなかった）

結合（包含の場合はINNER、抑制の場合はLEFTおよびNullのチェック）は、大量のデータセット（1,000行以上のデータセット）に最適です。

EXISTSは、すべての行に対してサブクエリを実行しているように見えるため、常に私を心配してきました（すべて140万？Yikes）。

私の直感によると、可能であれば、抑制テーブルの数を取得し、IN（1,000行未満の場合）およびINNER / LEFT結合（1,000行を超える抑制テーブルの場合）のいずれかを使用します。注、抑制するフィールドは、大きなベーステーブルですが、抑制テーブルはそうではありません。考え？

すべてのコメントおよび/またはアドバイスを事前に感謝します。

4

2 に答える 2

6

TSQLがSQLServerを意味すると仮定すると、NOT IN、NOT EXISTS、およびLEFT JOIN IS NULLの比較に関するこのリンクを見たことがありますか？NOT IN要約すると、比較される列がNULLになることはできず、 ...NOT EXISTSよりも効率的である限り。LEFT JOIN/IS NULL

INとEXISTSの違いについて覚えておくべきことがあります-EXISTSはブール演算子であり、基準が最初に満たされたときにtrueを返します。構文に相関サブクエリが表示されますが、EXISTSのパフォーマンスはINよりも優れています...

また、INとEXISTSは、値の比較の存在のみをチェックします。これは、参加するときに見られるようなレコードの重複がないことを意味します...

それは本当に依存するので、あなたが本当に最高のパフォーマンスを見つけるために外出しているなら、あなたはクエリプランが何をしているかをテストして比較しなければならないでしょう...

于 2010-08-30T20:42:03.573 に答える
0

使用する手法は関係ありません。フィルターまたは結合を適用するテーブルにインデックスがない場合、システムはテーブルスキャンを実行します。

RE：存在します

システムが140万行すべてに対してサブクエリを実行するわけではありません。SQL Serverは、内部のExistsクエリを実行し、それをメインクエリに対して評価するのに十分な機能を備えています。場合によっては、ExistsはJoinと同等またはそれ以上のパフォーマンスを発揮できます。

于 2010-08-30T20:41:24.730 に答える