sql - インデックスが必要または価値を持つようになるのはどの時点ですか?

Question

私はデータベースと SQL を学習中です。私が読んだことから、テーブルにインデックスを追加すると、パフォーマンスが約 (log(n)) から一定時間まで向上する可能性があります。

スペースの使用量が増えることを考えると、どの時点でテーブルにインデックスを追加する意味があるでしょうか?

たとえば、従業員テーブルを使用している場合、インデックスを追加する前に、テーブルにいくつのレコードが必要ですか?

この特定のケースでは、クラスター化されたインデックスは理にかなっていますか?

Answer 1

これについて考えるのに役立つ 2 つの例を次に示します。これらは技術的に正確であるとは言えませんが (たとえば、ランダム シークよりも効率的なディスクへの連続読み取りの効果があるため)、例として挙げることができます。

最初の例は、サイズが数ブロックの小さなテーブルを考えることです。テーブル内の特定の行を見つけるために、データベースはこれら 2 つのブロックを読み取り、必要なデータを取得します。

そのテーブルにインデックスがあった場合、インデックスはテーブルよりも小さい可能性があります。たぶん1ブロックのサイズです。オプティマイザがこのインデックスの使用を選択した場合、データベースは 1 ブロックのインデックスを読み取り、次に必要な行を含むテーブルの 1 ブロックを読み取ります。

前述のように、これは単なる例であり、正確ではなく現実をモデル化することを目的としています。実際には、インデックスが行のわずか 5% しか返さない場合でも、Oracle はインデックス付きのテーブルのフル テーブル スキャンを実行することがよくあります (または 11G ではそれより少ないのでしょうか?)。

2 番目の例では、テーブルのデータを変更します。テーブルの行が変更されるたびに ( INSERT、UPDATE、DELETE、MERGE)、テーブルのすべてのインデックスを更新する必要があります。

そのため、インデックスを使用すると、クエリが高速になり、更新が遅くなる場合があります。また、インデックスはスペースを占有します。それはあなたが支払う価格です。

「インデックスを追加する前に、テーブルにいくつのレコードが必要か」と尋ねますか? それはあなたが心配するべきではないので、あなたはそれを間違った方法で見ていると思います. テーブルの行がゼロの場合にインデックスを追加します。オプティマイザは正しいことを実行します。インデックスを使用する方が速い場合は、それを使用します。インデックスを回避してテーブルのフル スキャンを実行する方が速い場合は、そのようにします。

通常、主キーと外部キーに使用される列と、アクセスに頻繁に使用される列にインデックスを付けます。

一般に、テーブルが非常に大きい場合を除き、インデックスが使用する領域についてあまり心配することはありません (その場合、ビットマップ インデックスを調べる価値があるかもしれません)。これはスペースと時間のトレードオフですが、インデックスはインデックスが作成されているテーブルよりも小さくなります。

インデックスを圧縮するためのスペースが心配な場合の別のオプション。これはパフォーマンスに大きな影響を与えるべきではありませんが、必要なスペースは少なくなります。これはテーブル圧縮とは異なることに注意してください。

これは、Tom Kyte に「場合による」という答えを与えるには長い道のりです。おそらくできる最善のことは、特定の問題をベンチマークし、そこから進むことです。時期尚早の最適化を試みているようですが、これは決して良いことではありません。

Answer 2

一般に、すべてのテーブルにインデックスを付ける必要があります。特に、すべてのテーブルには主キーが必要です。これにより、インデックス（ほとんどの場合クラスター化インデックス）が自動的に作成されます。

ただし、主キーを作成しなかった場合でも、非常に小さなテーブルでもインデックスを作成することでメリットが得られます。

Answer 3

私の意見では、頻繁にアクセスする列 (主キー (これはデフォルトである必要があります)、検索条件の列など) でインデックスを使用し、WHERE節で使用します。回収速度が速くなります。

将来的にテーブルが大きくなる可能性があることを考慮して、インデックスを配置する必要があります。