より短い時間で実行されるSQLクエリ— WHERE句を使用するかどうかに関係なく、次の場合にクエリを実行します。
- WHERE句はインデックス付きフィールド(主キーフィールドなど)を扱います
- WHERE句はインデックス付けされていないフィールドを扱います
インデックス付きフィールドを使用している場合は、クエリWHERE
が高速になると思います。私は正しいですか?
より短い時間で実行されるSQLクエリ— WHERE句を使用するかどうかに関係なく、次の場合にクエリを実行します。
インデックス付きフィールドを使用している場合は、クエリWHERE
が高速になると思います。私は正しいですか?
すでに述べたように、これに対する決まった答えはありません。それはすべて特定のコンテキストに依存します。しかし、答えのためだけに。この簡単なクエリを実行します。
SELECT first_name FROM people WHERE last_name = 'Smith';
インデックスなしでこのクエリを処理するには、テーブル内のすべての行についてすべての列、last_nameをチェックする必要があります(全表スキャン)。
インデックスを使用すると、「Smith」が見つかるまでBツリーデータ構造をたどることができます。
非インデックスの場合、最悪のケースは線形(n)に見えますが、Bツリーの場合はlog nになるため、計算コストが低くなります。
'WHERE句を使用するクエリと使用しないクエリ'の意味はわかりませんが、ほとんどの場合、インデックス付きフィールドにWHERE句があるクエリは、インデックスなしフィールドにあるWHERE句よりもパフォーマンスが優れています。
パフォーマンスが同じになる(つまり、インデックス付けは重要ではない)1つの例は、where句で範囲ベースのクエリを実行する場合です(つまり、WHERE col1> x)。これにより、テーブルのスキャンが強制されるため、インデックスが作成されていない列での範囲クエリと同じ速度になります。
実際には、where句で参照する列、列のデータの種類、実行中のクエリの種類などによって異なります。
それはあなたが書いているwhere句のタイプに依存するかもしれません。単純なwhere句では、通常、使用しているフィールドにインデックスを設定することをお勧めします(uindexesは、PKよりも多くのインデックスを作成できます。ただし、違いを生むには、インデックスのsaragblewhere句を作成する必要があります。sarabilityに関するいくつかのガイドラインについては、次の質問を参照してください。
主キーのwhere句が遅くなる場合があります。
最も単純なのは、1行のテーブルです。インデックスを使用するには、インデックスとデータページの両方をロードする必要があります-2回の読み取り。作業を半分にするインデックスはありません。
これは退化したケースですが、問題、つまり選択された行の割合を示しています。または、より正確には、クエリを解決するために必要なページの割合。
目的のデータがすべてのページにある場合、インデックスを使用すると処理速度が低下します。非主キーの場合、テーブルがページキャッシュよりも大きく、アクセスがランダムである場合、これは悲惨な結果になる可能性があります。
ページは主キーで並べ替えられるため、最悪の場合は追加のインデックススキャンです。それほど悪くはありません。
一部のデータベースは、テーブルの統計を使用して、インデックスを使用するタイミングとテーブル全体のスキャンを実行するタイミングを決定します。しない人もいます。
つまり、選択性の低いクエリの場合、インデックスによってパフォーマンスが向上します。選択性の高いクエリの場合、インデックスを使用すると、さまざまな要因に応じて、パフォーマンスがわずかに低下したり、パフォーマンスが低下したりする可能性があります。
私のクエリのいくつかは非常に複雑で、where句を適用するとパフォーマンスが低下します。回避策として、一時テーブルを使用してから、それらにwhere句を適用しました。これにより、パフォーマンスが大幅に向上しました。また、特にLeft Outer Joinに参加したところ、パフォーマンスが向上しました。