感情と乾物を持って、WeChat で [荒廃した古代伝説] を検索し、この異なるプログラマーに注目してください。
最近、この問題について Zekang と Suxin と話したばかりなので、ここで簡単に要約します。
タイトルの「非常に小さなテーブルの場合、ほとんどの場合、インデックス作成よりも単純な全テーブル スキャンの方が効率的です」は、実際には「インデックスを使用するための条件」という質問に対する答えの一部です。完全な答えは次のとおりです。
- 非常に小さなテーブルの場合、ほとんどの場合、インデックス作成よりも単純な全テーブル スキャンの方が効率的です。
- 中規模から大規模のテーブルの場合、インデックスは非常に効果的です。
では、非常に小さなテーブルの場合、ほとんどの場合、単純な全テーブル スキャンの方がインデックス作成よりも効率的であるのはなぜでしょうか? その理由は次のとおりです。
MySQL のデフォルトのストレージ エンジンは InnoDB です。InnoDB では、インデックスは B+ ツリーを通じて実装されます。MySQL データはクラスター化インデックスのリーフ ノードに保存されます (クラスター化インデックスは主キー インデックス、プライマリ インデックスとも呼ばれます)。
インデックスを構成するフィールドと主キーは、補助インデックス (一意のインデックスと非一意のインデックスを含む) のリーフ ノードに格納されます。
クエリされたフィールドがインデックスの一部ではない場合は、補助インデックスから見つかった主キー値を使用して、クラスター化インデックス内のデータをクエリする必要があります。このプロセスは、テーブルに戻るとも呼ばれます。
したがって、テーブルが比較的小さい場合は、(テーブルに戻る必要があるため) インデックスを経由するよりもテーブルを直接走査する方が明らかに高速です。
注: まず、この回答の暗黙の条件は、クエリされたデータがインデックスの一部ではなく、テーブルを返す操作が必要ないことであることに注意してください。次に、クエリ条件が主キーではない場合、データはクラスター化インデックスから直接取得できます。
概念を簡単に要約すると次のようになります。
B+ツリーインデックス
ほとんどの MySQL ストレージ エンジンのデフォルトのインデックス タイプです。
フルテーブルスキャンを実行する必要がなく、ツリーのみを検索すればよいため、検索速度が大幅に速くなります。
B+ ツリーの順序付けされた性質により、検索だけでなく並べ替えやグループ化にも使用できます。
複数の列をインデックス列として指定でき、複数のインデックス列がまとめて 1 つのキーを形成します。
完全なキー値、キー値の範囲、およびキー プレフィックス ルックアップに適用されます。キー プレフィックス ルックアップは、左端のプレフィックス ルックアップにのみ適用されます。インデックスが付けられた列の順序で検索が行われない場合、インデックスは使用できません。
InnoDB の B+Tree インデックスは、プライマリ インデックスと補助インデックスに分かれています。メイン インデックスのリーフ ノードのデータ ドメインには完全なデータ レコードが記録され、このインデックス方法はクラスター化インデックスと呼ばれます。データ行を 2 つの異なる場所に格納する方法はないため、テーブルにはクラスタード インデックスを 1 つだけ含めることができます。
補助インデックスのリーフ ノードのデータ フィールドには主キーの値が記録されるため、補助インデックスを使用して検索する場合は、最初に主キーの値を見つけてから、メイン インデックスで検索する必要があります。
カバーインデックス
インデックスには、クエリが必要なすべてのフィールドの値が含まれています。
次のような利点があります。
- 通常、インデックスはデータ行のサイズよりもはるかに小さいため、インデックスを読み取るだけでデータ アクセスの量を大幅に削減できます。
- 一部のストレージ エンジン (MyISAM など) はインデックスのみをメモリにキャッシュし、データはオペレーティング システムのキャッシュに依存します。したがって、インデックスのみにアクセスすると、システム コール (通常は時間がかかります) の使用を回避できます。
- InnoDB エンジンの場合、補助インデックスがクエリをカバーできる場合、メイン インデックスにアクセスする必要はありません (テーブルに戻る必要はありません)。
インデックスの使用条件
-
非常に小さなテーブルの場合、ほとんどの場合、インデックスを作成するよりも単純な全テーブル スキャンの方が効率的です。
-
中規模から大規模のテーブルの場合、インデックスは非常に効果的です。
-
ただし、非常に大きなテーブルの場合は、インデックスの作成と維持のコストもそれに応じて増加します。この場合、レコードを 1 つずつ照合するのではなく、クエリが必要なデータのセットを直接区別できる技術を使用する必要があります。たとえば、パーティショニング技術を使用できます。
記事は継続的に更新されており、WeChatで「荒廃した古代伝説」を検索するとすぐに読むことができます。