何百万行ものテーブルがあります。特定の列値を持つすべての行を見つける必要があります。その列はインデックスにないため、テーブル スキャンが実行されます。
しかし、列を先頭に (主キーが続く) インデックスを追加し、クエリを実行してから、インデックスを削除する方が速いでしょうか?
ユーザーが探している列を指定しているため、インデックスを永続的に追加することはできません。
何百万行ものテーブルがあります。特定の列値を持つすべての行を見つける必要があります。その列はインデックスにないため、テーブル スキャンが実行されます。
しかし、列を先頭に (主キーが続く) インデックスを追加し、クエリを実行してから、インデックスを削除する方が速いでしょうか?
ユーザーが探している列を指定しているため、インデックスを永続的に追加することはできません。
考えるべき2つの質問:
候補列の数が少なく、データがあまり変更されない場合は、一部またはすべての候補列に永続インデックスを追加することを検討してください。
「冒涜!」と聞きました。ほとんどの情報源は、テーブルのすべての列に「インデックスを付けない」ように指示していますが、そのアドバイスは、テーブルが頻繁に変更されるという一般的な仮定に基づいています。
追加のストレージで料金を支払うだけでなく、データが変更されたときにパフォーマンスが低下します。
どれだけ小さいか、どれくらい多いか、そしてトレードオフはそれだけの価値がありますか?「遅すぎる」は通常主観的な測定であるため、優先順位を判断する方法はありません。
それを試して、インデックスのサイズを測定してから、それらが検索に与える影響を測定する必要があります。コストと顧客の満足度の向上とのバランスを取る必要があります。
[追加]ああ、もう1つ、一時インデックスはテーブルスキャンよりも物理的に遅いだけでなく、同時実行性を破壊します。通常(常に?)テーブルのインデックスを再作成するには、完全なテーブルロックが必要であるため、実際には、一度に1つのユーザー検索しか実行できませんでした。
幸運を。
私は DBA ではありませんが、インデックスを作成するにはテーブルをスキャンする必要があると思います。
その列に複数のクエリがある場合を除き、インデックスを作成しないことをお勧めします。
ただし、両方の方法で説明プラン/実行時間を確認することをお勧めします!
他の誰もが言っているように、その列のフル スキャンを実行するよりも、インデックスを追加する方が確実に高速ではありません。
ただし、クエリ パターンを追跡して、どの列が最も検索されているかを調べ、少なくともそれらの列にインデックスを追加することをお勧めします。3 ~ 4 個のインデックスを使用すると、クエリの 90% が高速化されることがわかる場合があります。
各列に永続的なインデックスを追加し、クエリで返されるすべての列を含まれる列のリスト (カバリング インデックス) に追加しない限り、ソリューションは拡張されません。これらのインデックスは非常に大きくなり、そのテーブルへの挿入と更新は少し遅くなりますが、ユーザーが検索列を任意に選択できるようにしている場合、選択の余地はあまりありません。
柱は何本ありますか?データはどのくらいの頻度で更新されますか? 挿入と更新はどのくらいの速度で実行する必要がありますか? これらの質問に対する答えによっては、トレードオフが伴います。十分な実験とテストを行って、物事がどのように機能するかを確実に把握してください。
ただし、元の質問に対して、単一のクエリの目的でインデックスを追加および削除することは、クエリ中に複数の選択を行う場合にのみ有益です (たとえば、選択は、返される行ごとに実行されるサブクエリにあります) )。
そうではないでしょう。インデックスの作成は、計算の複雑さが同じであっても、単に列をスキャンするよりも複雑です。
とはいえ、列はいくつありますか? 1 回の検索のクエリ時間が長すぎる場合、それぞれにインデックスを作成することはできませんか?
インデックスを追加するにはテーブル スキャンが必要なため、永続的なインデックスを追加できない場合は、単一のスキャンの方が (わずかに) 高速になるように思えます。
いいえ、それは速くありません。より速いのは、インデックスを追加してそのままにしておくことです!
もちろん、すべての列にインデックスを付けるのは現実的ではないかもしれませんが、そうなる可能性もあります。データはどのようにテーブルに追加されますか?
クエリの複雑さによって異なります。データを 1 回取得する場合は、テーブル スキャンを実行する方が高速です。ただし、同じクエリで関連情報を得るために複数回テーブルに戻る場合は、インデックスの方が高速です。
関連するもう 1 つの戦略は、テーブル スキャンを実行し、すべてのデータを一時テーブルに配置することです。次に、THAT にインデックスを付けると、その後のすべての選択、グループ化、およびインデックス付きデータのサブセットに対して他の多くのクエリを実行できます。利点は、一時テーブルを使用して関連テーブルで関連情報を検索する方がはるかに高速であることです。
ただし、最近はスペースが安いため、ユーザーが実際にシステムをどのように使用しているかを調べ、頻繁に使用する列にインデックスを追加することをお勧めします。ユーザーが常にすべての検索パラメーターを使用しているのを見たことがありません。