多くのインデックスの種類と、インデックスのさまざまな使用方法があります。使用およびメンテナンスするさまざまな方法について説明します。インデックスは、比較的少数の行をテーブルから効率的に取得する方法です。インデックスはソートの回避にも役立ちます。さまざまなインデックスの種類がサポートされています。実行するとデフォルトで設定されます。インデックスがあります。ツリーの各ブランチでデータ量がほぼ同じになるようにバランスを保とうとします。行を見つけるためにトラバースする必要があるレベルの数が常に同じ範囲内に収まるようにします。インデックスの使用効果が高いのは、等価クエリと範囲クエリです。値の取得にも使用できます。設計はキャッシングと非常に相性が良く、それは部分的にしかキャッシュされない場合でも同じです。前のハッシュインデックス​は等価比較のみに有用ですが、使用機会はありません。これは、トランザクションセーフではなく、クラッシュ後は手動で再構築する必要があり、フォロワーに複製されないためです。使用に比べてあまり利点がありません。以降のハッシュインデックスは、ログ先行書き込みが行われ、フォロワーに複製されるようになりました。行にマッピングする必要がある場合に有用です。つのキー値がある状況向けに最適化されています。配列値のインデックス付けや全文検索の実装に適しています。インデックスは、一般的でバランスの取れたツリー構造を構築するために使用でき、等価比較や範囲比較よりも複雑な操作に使用できます。全文検索だけでなく、ジオメトリデータ型のインデックス付けにも使用されます。インデックスを最大限に活用する方法です。パッケージ​を参照してください。プランナーが選択する理由は数多くあります。ほとんどの場合、理由が明白でないとしても、プランナーは正しい選択を行います。同じクエリでインデックススキャンを使用する場合と使用しない場合があっても問題ありません。テーブルから取得される行数は、クエリで取得する特定の定数値によって異なる場合があります。インデックスを使用しないとしても、それは適切である可能性があります。この場合、シーケンシャルスキャンの方がインデックススキャンよりもずっと高速である可能性が高いため、クエリプランナーは実際に、そのようにクエリを実行するコストの方が低いと正しく判断しました。部分インデックス部分インデックスはテーブルのデータのサブセットのみをカバーします。句を伴ったインデックスです。インデックスのサイズを減らすことでインデックスの効率を高めるという考えです。インデックスが小さいほど、ストレージ使用量が減り、メンテナンスが容易になり、スキャンが高速になります。その後、フラグの付いたコメントをバッチで処理します。この場合、次のようにしてインデックスを作成する必要があります。TRUE;このインデックスはかなり小さく保たれ、より複雑なクエリで必要とされる場合に他のインデックスと併用することもできます。式インデックス式インデックスは、データに対する関数または変更に一致するクエリに有用です。その関数の結果にインデックスを付けて、生のデータ値による検索と同等の検索効率を実現できます。サインイン用のメールアドレスを保存することをユーザーに求める一方で、認証では大文字と小文字を区別しない場合を考えます。条件で実行することが可能です。そのようなクエリでインデックスを使用するには、次のような式インデックスを使用するのが唯一の方法です。フィールドにタイムスタンプが保存されているが、日付にキャストされた値によって検索を行うことを考えます。含むクエリで使用できます。一意インデックス一意インデックスは、同じ値を持つ複数の行がテーブルに存在しないことを保証します。つの理由でメリットがあります。一意インデックスのルックアップは非常に高速です。検証を使用しても、無効なレコードを作成する同時ユーザーがすでに存在する可能性があり、また存在するため、真の意味での一意性は保証されません。したがって、インデックスまたは一意性制約のどちらかを使用して、常にデータベースレベルで制約を作成します。一意インデックスと一意性制約の違いはほとんどありません。式インデックスと部分インデックスは一意性制約として作成できないため、一意インデックスの方が下位と考えることができます。式に対する部分的な一意インデックスも可能です。複数列インデックスを作成できますが、作成することに意味がある状況を理解することが重要です。つの複数列クエリに結合して使用することができます。インデックスを使用します。そのため、複数列インデックスを作成する前に必ずベンチマークを行い、作成を正当化してください。インデックスには常にコストがかかり、複数列インデックスが最適化できるのはインデックス内の列を同じ順序で参照するクエリに限られるのに対し、複数の単一列インデックスの方が、より多くのクエリにパフォーマンスの向上をもたらします。複数列インデックスが明確に意味を持つ状況があります。使用するクエリでは使用されません。そのため、これがアプリケーションのクエリパターンと一致する場合は、複数列インデックスのアプローチを検討する価値があります。インデックスを作成すると冗長になることにも注意してください。インデックスのエントリは、デフォルトでは昇順でソートされます。インデックスの異なるソート順を指定することに意味がある場合もあります。ページ番号を付けた記事のリストを、公開が最も新しいものが先頭に来るようにソートして表示する場合を考えます。列を指定することができます。この場合、次のようにインデックスを作成できます。場合、インデックスは必ずしもテーブルを参照する必要はない、という点は注目に値します。ソート順でテーブルをクエリして結果を制限するので、同じ順序でインデックスを作成すると多少のメリットが得られます。必要な行をインデックスから正しい順序で検索し、データブロックにアクセスしてデータを取得します。データブロックをシーケンシャルに読み取って結果をソートする可能性が高くなります。動作が必要なときの単一列インデックスです。それ以外の場合、インデックスはどの方向にもスキャン可能なので順序はすでに利用可能であるからです。ように複合的なソート順をクエリが要求するときに複数列インデックスに対して使用する場合、さらに関連性が高くなります。インデックスは、すべての行データを保持するわけではありません。ディスクにアクセスして行データをフェッチします。ディスクにアクセスしてその情報をフェッチする必要があります。以上を踏まえると、場合によってはインデックスを使用しても実際には意味がない理由がわかります。インデックスは、ディスクルックアップの数を減らせるほどに選択的でなければ、価値がありません。十分に大きいテーブルに対するプライマリキールックアップは、インデックスを有効利用します。ターゲット行をインデックスから見つけて、ディスクから選択的にフェッチすることができます。都市ルックアップテーブルのようにごく小さなテーブルに関しては、都市名で検索する場合でもインデックスは望ましくない可能性があります。インデックスを無視してシーケンシャルスキャンを優先することを決定する可能性があります。テーブルの重要な部分にヒットするクエリではシーケンシャルスキャンを実行することを決定します。その列にインデックスがある場合、決して使用されないデッドインデックスになります。インデックスには必ずコストがかかり、具体的にはストレージとメンテナンスの面でコストがかかります。記事を参照してください。データベースにできるだけ近いデータベースを使用してください。サーバーの設定、テーブル内のデータ、インデックス、クエリなど、いくつかの要因に依存します。小さなサブセットを載せた開発マシン上でクエリにインデックスを使わせようとしてもうまくいきません。データセットが小さすぎるのでインデックス全体を読み取るのはそのオーバーヘッドに見合わないと判断して、ディスクからデータをフェッチします。コストよりも低くなります。インデックスチューニングの実行は、本番環境か、できるだけ本番環境に近いステージング環境で行う必要があります。データベースプラットフォームでは、簡単な手順で​本番データベースを別の環境にコピーできます。本番データベースにインデックスを適用する準備ができたら、インデックスを作成するとテーブルが書き込みロックされることに注意してください。テーブルが大きい場合、サイトが数時間ダウンする可能性があります。構築にかかる時間はかなり長くなりますが、書き込みをブロックするロックは必要ありません。コマンドでは、書き込みをブロックするが読み取りはブロックしないロックが必要になります。最後に、しばらく時間が経つと、テーブルの行が頻繁に更新または削除される場合は特に、インデックスは断片化して最適でなくなります。実行してインデックスのバランスを回復し、最適化することが必要な場合があります。親テーブルに書き込みロックがかかるため、大きなインデックスの再インデックス処理には注意が必要です。つの戦略は、同じテーブルと列に対して別の名前で同時にインデックスを構築し、元のインデックスを削除し、新しいインデックスの名前を変更するというものです。この手順は、時間はかかりますが、ライブテーブルに長時間のロックをかける必要がなくなります。多くの柔軟性を提供します。以上のヒントは、データベースを正常な状態に保ち、クエリを高速化するために役立ちます。Salesforce.com。