MySQLインデックスの詳細な使用、原理分析
[予告]
著者による記事：記事の理解しやすい成形加工の生産に自分自身の経験と一緒に張Yaofeng、
！書き込みが指定してください、ありがとう再現、簡単ではありません
ビッグデータコードケース住所：https://github.com/Mydreamandreality / sparkResearch
innodbエンジンには、合計4つのインデックスタイプ、2つのインデックスメソッドがあり、主に本番環境でのインデックスの選択、データ構造の選択について説明します
インデックスヒット率、SQL実行プランは私の以前の記事を表示できます
インデックスタイプ：
- 1.通常のインデックス
- 2.一意のインデックス
- 3.全文索引
- 4.空間空間インデックス
インデックス方式：
- 1. btreeインデックスメソッド
- 2.ハッシュインデックス方式
詳細なインデックスタイプ：
- 1.まず、インデックスタイプNormalは、最も一般的に使用されるインデックスタイプであり、最も基本的なインデックスタイプでもあります。制限はありません。フィールドにNormalを設定するか、ジョイントインデックスを作成できます。単一条件クエリ、複数条件クエリ、またはその他の左結合操作を行う場合、MySQLオプティマイザーは自動的にこのインデックスタイプを使用してクエリ速度を最適化します。このインデックスが有効かどうかを知りたい場合は、
explainコマンドを使用できます。SQL実行プランを確認してみましょうSQL実行プランの詳細については、以前のブログを参照してください。 - 2.名前が示すように、Uniqueは一意のインデックスです。Uniqueインデックスは、通常のインデックスに基づいて一意の制約を追加するためのものです。100万レベルのデータでテストしましたが、Normalと比べてパフォーマンスに大きな違いはありません。このインデックスのアプリケーションシナリオは非常に優れています。たとえば、多くの場合、データにはインデックスを作成する必要があるフィールドがあり、このフィールドの値は一意である必要があります。その場合、一意のインデックスを使用することをお勧めします
- 3.フルテキストフルテキストインデックス作成は理にかなっています。一般的に言えば、Elasticsearchが必要です。MySQLでのフルテキストインデックス作成はあまり使用されていませんが、フルテキストインデックス作成の基本単位は間違いなく単語です。MySQLのトークナイザはそうではありませんそれがesと同じくらい強力であるかどうかを確認します。つまり、このインデックスのアプリケーションシナリオは、特定のフィールドに格納された大きなテキストであり、フルテキストインデックスを使用できます。
- 4.正直に言うと、空間インデックスは使用されていません。このインデックスはinnodbエンジンでは使用できないため、MYISAMエンジンの空間データタイプフィールドで使用する必要があります。MYSQLには4つの空間データタイプがあります。 GEOMETRY、POINT、LINESTRING、POLYGON、MYSQLはSPATIALキーワードを使用して展開するため、これを使用して通常のインデックスタイプの構文を作成して空間インデックスを作成し、空間インデックス列を作成してNOT NULLとして宣言する必要があります
詳細なインデックス方法：
インデックスメソッドこのMySQLは2つの
- 1. BTREEはB +ツリーであり、最も使用されます
- 2.ハッシュはKとVのデータ構造です。この種の範囲検索とノード検索はあまりサポートしていません。
インデックスとは何ですか？
インデックスとは何か考えたことはありますか？インデックスを適度に追加した後、クエリの効率が非常に高くなる理由
実際、端的に言えば、インデックスはデータ構造であり、その役割は、MySQLのB +ツリーによって実装されるインデックスと同様に、クエリを最適化することです。B+ツリーはデータ構造です。インデックスを追加しない場合は、データをクエリしますテーブル全体をスキャンしてから、データを照合する前にフルテーブルスキャンを実行する必要があります。これは大量のデータですか？インデックスはディクショナリのシーケンステーブルに相当します。特定のデータをチェックする場合は、シーケンステーブルで直接kを見つけることができます。効率の向上は非常に高くなります。
では、なぜB +ツリーデータ構造、ハッシュインデックス、Bツリーを使用することをお勧めしますか？バイナリツリーの完全なバランスを取ることはできないのですか？
まず、ハッシュインデックスについて話しましょう。この種のインデックス検索速度は高速ですが、これ以上の範囲の検索など、範囲検索をサポートしていないため不快です。kvがこの種のクエリをどのようにサポートするかは、一般的なケースではほとんど使用されません。ハッシュインデックス
次に、実際には名前を確認するだけで、b-treeとb +ツリーの間には大きな違いがあります。複数の+だけでなく、実際にはb +ツリーの非リーフノードはリーフノードに冗長であり、b +ツリーリーフノード間にポインタがあります。特に速いものよりも大きいものまたは小さいものを見つけることは、時間に対する空間のソリューションです
平衡二分木は範囲検索をサポートしています。b+数値（b数値も可能）ノードが複数の要素を格納できるため、なぜそれを使用しないのですか？これは何が原因ですか？抽象的に考えると、2つのツリーがあります。b+ツリーは複数の要素を格納するため、バイナリツリーよりも低いツリーであるため、要素の検索が高速になり、特定のio操作が削減されます。
。。。待って、待って、インデックスはあまりにも多くのポイントを言うことができます、少しだけ知って、あなたが自由になったらもっと深く進んでください
インデックスの使用上の注意
- 1.データの量が多い場合、インデックスは明らかな効果を発揮します。システム内のデータの量が多くない場合は、インデックスを生成する必要がなく、ディスク領域を浪費しません。
- 2.インデックスはクエリ速度を向上させますが、更新速度を低下させます
- 3.私はいくつかの危険な考えを聞きました。。インデックスが有効かどうかはわかりませんが、とにかく、すべてのフィールドにインデックスを追加しました。。。これは恐ろしいです。インデックスを作成すると、インデックスファイルのディスク容量が消費されます。通常どおりにインデックスを作成できます。問題ありません。インデックスを使いすぎないようにしてください
- 4.ビジネスシナリオに応じて適切なインデックスを選択します
