私はデータベースにあまり精通していませんが、現在、インデックス作成メカニズムを理解しようとしています。
私が知っていることから、RDBMSでは、列にインデックスを付けると、その列による検索が高速になります。これはトリプルストアにも当てはまります。インデックスのみが、主にサブジェクト、次にオブジェクトなどで検索することを想定しています。
RDBMSについてはわかりませんが、トリプルストアでは、複数のインデックスを定義して、各クエリに最適なインデックスをストアに選択させることができます（うまくいけばこの権利を理解できました）。当然、次の質問が表示されます。
可能性のあるすべてのインデックスをトリプルストアに追加し、RDBMSに拡張してはいけないのはなぜですか。各列にインデックスを作成しないのはなぜですか（私は怠zyではないと仮定して）。
回答:
基本的に、インデックスは余分なテーブルであり、プライマリキーはインデックスを作成するフィールドであり、コンテンツはメインテーブルのプライマリキーのみであるためです。したがって、すべての更新は、更新するフィールドを使用するすべてのインデックスで複製する必要があります。
これは、インサートで特に顕著です。テーブルに行ったすべての挿入を、他の20個のテーブルに複製する必要があると想像してください。それは痛々しいほど遅くなるだろう。
これは、複合インデックス、クラスタ化インデックス、およびフルテキストインデックスではさらに悪化することに注意してください。ただし、この問題をまだ複雑にしたくありません。
インデックスは基本的に追加のデータ構造であり、構築および保存する必要があります。indeを構築すると（書き込み操作中に）CPUパワーが無駄になり、保存するとディスク容量が無駄になります。
使用しないインデックスを作成して保存するのはなぜですか？
必要な場合にのみインデックスを配置します。私がデータベーススキーマを開発するときの経験則として、すべてのテーブルは、最初にPKプライマリキークラスター化インデックスを取得します。これは、そのテーブルのデータの一意の識別子になります。Inは1列または複数列にすることができます。
その後、通常、一意性を強制する列に非クラスター化一意インデックスを追加します。
これは基本スキーマです。アプリケーションが開発され、成熟するにつれて、パフォーマンスの懸念とデータのクエリ方法に基づいて、必要に応じてインデックスを追加します。
追加されるすべてのインデックスは、使用される間隔を増やし、さらにメンテナンスを追加します。したがって、インデックスを賢明に選択してください。
インデックスの長所は、1）すばやく検索できるデータ構造と、2）実際のテーブルよりもコンパクトであり、ディスクにページングされるのではなく、より多くのインデックスがメモリに収まることです。
すべての列にインデックスがある場合、インデックス自体は、それらが表すテーブルよりも多くのスペースを使用します。データベースが実際にすべてのインデックスを使用している場合、インデックスをメモリにスワップインおよびスワップアウトするだけで時間がかかります。さらに、すべてのインデックスは、不活性、更新、または削除時に更新する必要があります。
それを超えて、単一の列のインデックスはあなたができる最高のものではありません。ほとんどのリレーションデータベースは、実際には複数の列のインデックスを許可し、これらの列の順序は重要です。たとえば、1980年から1984年の間にクラスからデュークに行ったすべての人のデータベースを検索する場合、（School、ClassYear）のインデックスが必要です。クエリは同じ列のインデックスを使用できませんが、逆になります。
したがって、可能なすべてのインデックスを作成するには、少なくともn！インデックスに列を配置する方法。5列のみの場合、120の可能なインデックスがあります。
考えられるインデックスは非常に多いため、アプリケーションにとってどのインデックスが有用かを判断し、それらだけを作成する必要があります。
テーブル内のすべての列にインデックスを作成すると、通常、スペースが無駄になり、他の人が述べたように、挿入/更新操作が遅くなる可能性があります。インデックスを使用してクエリを高速化します。その列の値を照会するときにパフォーマンスの低下に気づいた場合にのみ、列にインデックスを追加することをお勧めします。
一部のデータベースでは、テーブルの主キーのインデックスが必要な場合があります。そのため、その主キーについて選択できない場合があります。また、非常に大きなテキスト列がある場合、フルテキスト検索およびインデックス用に設計された特定のテクノロジがありますが、小さな数値列に使用するのと同じ種類のインデックスとは限りません。