以前の研究では、我々は、インデックスデータ構造MySQLと2つのMyISAMとInnoDBストレージエンジンBツリーインデックスの原理の実現を理解しています。あなたは、インデックス、強い兄の今日とチャット最適化MySQLのインデックスの背後にあるメカニズムを理解すれば。
しかし、我々はいくつかの概念を理解する必要があり、その前に：
-
サムスンシステム
-
選択インデックス
-
Bツリーインデックスの制限
サムスンシステム
まず、「サムスン・システム」のクエリのためのインデックスかどうかを評価する方法で見てみましょう：インデックスは星を取得するために一緒に関連するレコードを置く;同じソート順とシーケンスデータが得賞のインデックスを検索した場合;インデックス内のカラムは、すべての列のクエリのニーズが含まれている場合は、サムスンを取得することです。
サムスンシステムによれば、私たちはより良い指標の品質を評価することができます。
選択インデックス
選択性は、インデックス、インデックス値は繰返さない（また、ベースとも呼ばれる）、及び1の間の1 /列の範囲内のデータテーブルのレコード（行）の合計数の比を指します。見ているとき、クエリの高い選択理由は、高い選択指数の指数の高効率化は、より多くのラインアウトのMysqlフィルタすることができます。選択ユニークインデックスが、これは選択性の最良の指標である、1である、パフォーマンスが最高です。我々は、テーブルの列にインデックスとして性別・フィールドである場合には、そのような選択性が低いと、インデックスの効果は非常に明白ではありません。
Bツリーインデックスの制限
Bツリーインデックス、関連するコンテンツタイプは、我々が知っている前のツイートによると、インデックスツリーはまた、いくつかの制限が原因となった、注文されています。
-
それは探し始めるための一番左の列インデックスに基づいていない場合は、インデックスを使用することはできません。
-
直接決勝にジャンプしないマッチング・インデックスの前に列をスキップすることはできません列のインデックスを、スキップすることはできません。
-
あなたは、列範囲クエリクエリを持っている場合は、その右側にあるすべての列が最適化クエリにインデックスを使用することはできません。
その後、我々はいくつかの高性能インデックス戦略を話をする必要があります。
選択インデックス
上記の選択指数によると、私たちは二つの非インデックスを作成することはお勧め状況を確認できます。
-
表のデータの比較は、例えば、2000またはテーブルの百にもいくつかのレコードが、インデックスを構築する必要はありません低いため、クエリは、全表スキャンだけで罰金を行います。もっと考えられているどのように多くのレコードのように、この個人が個人的な意見を持って、私の個人的な経験は、分割ラインとして5000に基づいています。
-
場合は、比較的低い選択指数。選択性が低い場合は、インデックスを服用した後のデータの検索エンジンが返すのデータ行と行の合計数は、インデックスを取っつ以上の操作は、より速く、完全なテーブルに直接アクセスした方が良いよう、ほぼ同じです。
プリフィックス索引
時々、インデックスへの必要性は、列の長さは、長いインデックスが大きいと遅くなるようにする。この時間です。そして、あなたは、インデックスを作成するために、接頭辞列のあるプリフィックス索引、代わりの列全体を使用することができ、指数は大幅に、スペースを節約効率指標を向上させることができます。など11のように列の長さ（レジスタ値：パフォーマンス）、我々は7の長さをとっているプリフィックス索引（インデックス値：実行）を行います。
しかし、それはまた、選択指数を削減する、接頭辞は、選択性が低く、短すぎる指標失われた値です。それは、選択プレフィックスを確保するために、高い十分な長さを選択する必要があるので、インデックスが過度に長すぎるリードすることはできません。
私たちは、次の文でカラムの選択インデックスのサイズを計算することができます：
SELECT COUNT(DISTINCT 索引字段名)/COUNT(*) FROM 表；//单列索引
SELECT COUNT(DISTINCT (LEFT(索引字段名,前缀长度)))/COUNT(*) FROM 表；//单列前缀索引
SELECT COUNT(DISTINCT (CONCAT(索引字段名1,索引字段名2)))/COUNT(*) FROM 表；//多列索引
SELECT COUNT(DISTINCT (CONCAT(索引字段名1,LEFT(索引字段名2,前缀长度))))/COUNT(*) FROM 表；//多列前缀索引選択インデックスの長さが非常に大きくない場合には十分な大きさと、私たちは、プリフィックス索引を確立することができるようになります。
インデックスの列には、適切な順序を選択します
複数列インデックスでB木、インデックス列が最初の一番左の列に従ってソートされていることを指標手段の順序は、第二の列が続く、など。したがって、インデックスはORDER BY、GROUP BY句とクエリがDISTINCTなどを必要と完全一致を満たす列の順序、昇順または降順で走査することができます。したがって、列の順序は不可欠マルチカラムインデックスです。
どのようにインデックスそれのための列の順序を選択するには？最高のカラムの最前線に最も選択インデックス：選択上記の表現によると、我々は以下の結論を引き出すことができません。
並べ替えとグループ化を考慮することが必要な場合には、列の一番上に、最も高い選択指数は、一般的には非常に良いです。この効果は、場合にのみ、検索条件を最適化するための指標。しかし、性能だけでなく、すべてのインデックス列の選択に依存し、また、特定の値の検索条件に関連し、そして値の分布に関連しています。
通常よりも技術的な値が高いときに、特定の条件下で、インデックスの接頭辞を使用する場合、問題が来ました。例えば、いくつかのアプリケーションでは、異なる特別な管理者アカウントと一般会計があり、システム内の他のすべてのユーザーが、ユーザーの友人です。友人の巨大なリストのこのアカウントは簡単にパフォーマンスの問題が発生するサイトサーバーにつながることができます。この場合、でもすべてではなく、ユーザの友人のリストを取得する、またはテーブル内のほとんどすべてのレコードを取得するとき - つまり、インデックスは基本的に役に立ちません。
このような状況を解決するには、アプリケーションのコードを変更するこれらの特別なユーザーは、このようなユーザーのために、このようなクエリ操作を実行することは禁止されて区別することです。むしろインデックスを使用するよりも。
InnoDBは自動インクリメントの主キーでの使用を推奨しました
前のツイートでは、我々は、InnoDBエンジンでのMySQLが最もB木クラスタ化インデックスを使用したことを知って、データレコード自体は、メインインデックスのリーフノードに格納されます。これは、MySQLの適切なノードに挿入され、その主キーによれば、新しいレコードが挿入されてあるので、いつでも、主キーシーケンスを記憶されたレコードの各データノードのリーフ（メモリページまたはディスク・ページのサイズ）内で同じ必要ページの負荷率が（デフォルト15/16としてのInnoDB）に達した場合と場所は、新しいページ（ノード）が開かれています。
テーブルがインクリメント主キー、新しいレコードが挿入されるたびに使用している場合、それは、インデックスノード、充填されたとき、それは自動的に新しいページが開かれるの現在位置に加え、その後のシーケンスを記録します。下図のように：
これは、次近似を埋めるために、コンパクトなインデックス構造を形成することになります。それぞれが、挿入されている既存のデータを移動するために、効率が非常に高いので、それはインデックスを維持する上で多くのオーバーヘッドを追加しません必要はありませんので。
（などのID番号または学生番号、あれば）非インクリメントプライマリキー場合は、ランダムな挿入に似各プライマリキー値ので、新しいレコードが既存のインデックスページに挿入されるたびに、特定の中間位置を持っている必要があります。
この時点で、MySQLのも目的のページがディスクに書き戻され、キャッシュからクリアされている可能性があり、適切な位置や動きのデータに新しいレコードを注文しなければならなかった、あなたは多くのオーバーヘッドを追加し、ディスクからリードバックする必要があります頻繁に移動し、ページング操作は、破片の多くを引き起こしながら、それはコンパクトな索引構造ではなかった、フォローアップは、ページを埋める最適化table文と最適化により、テーブルを再構築しなければなりませんでした。可能であればしたがって、InnoDBの上のエネルギー自給プライマリキーフィールドに設計する必要があります。
もちろん、魅力は、アカウントに分散データベース・システムの問題で繰り返さセルフID IDの使用の増加を取ることはありませんが、我々はまた、問題を解決し、データベーステーブルの特別なインクリメントIDを生成するかのRedis経由することができ、もちろん、雪の結晶化アルゴリズムを使用すること。要するに、B木クラスタ化インデックスを理解するために、我々は比較的効率的かつ合理的なマスター・キーを作成するために、得られた知識を使用することができます。
いくつかのカバレッジを達成するために、関連する遅延インデックス
また、つぶやきの概念にも、すべてのフィールドが選択欄カバーはインデックスをカバーするために使用されるインデックス「カバーのインデックス」を述べました。被覆率は、バック部を照会する必要なしにのみ、インデックステーブルから必要なデータを得ることができ、インデックスが、オーダーであるので、その結果、範囲クエリI / O集中高効率。
私たちはめったにインデックスでカバー状況に遭遇していないが、多くの場合、あなたがカバーするインデックスを使用することはできませんので、以上、コラム欄を選択し、一般的です。だから、私たちはそれをカバーするために、インデックスを使用してみましょうする方法はありますか？
私たちはそのインデックスに関連する遅延を使用することができるようになります。この時間は、MySQLのクエリ一致が続いて、これらの値のIDに基づいて、クエリデータID（またはその他の固有の属性フィールド）のFROM句で発見された最初の数段落をカバーするために使用することができますすべての列の値の必要性を得るために、クエリに一致する層。あなたが使用することはできませんが、このインデックスはクエリをカバーしますが、インデックスの使用をカバーするいくつかの完全にできないよりも少なくとも優れています。
しかし、ここにも強い弟は、Mysql5.6リビジョンが「プッシュ条件指数（インデックス条件プッシュダウン）」と呼ばれているストレージエンジンのAPIが大幅に向上し、反映していることに言及。この機能は大幅滞在が調整されたので、次のつぶやきは、強い弟が表示されます、現在のクエリを改善します。
インデックス・スキャンを使用すると、ソートを行います
あなただけすぐにインデックスレコードの次のレコードから移動する必要があるため、インデックス自体をスキャンする非常に高速です。インデックスがクエリに必要な列の全てをカバーすることはできませんしかし、もし、それが戻って対応する行に一度テーブルにすべての問い合わせへのインデックスエントリをスキャンする必要はありません。これは基本的にランダムI / Oであるため、インデックスデータの順序は、通常、完全なテーブルが特にときI / O集約型のワークロード、順次遅いスキャンよりも速度を読み取ります。
まったく同じ順序と、すべての列（または正のフラッシュバック・シーケンス）の方向の句BYインデックス列の順序およびORDERの順番が同時にある場合のみ、MySQLは結果が行う並べ替えにインデックスを使用することができます。インデックスは、フィールドが場合にのみ、最初のテーブルのためにその全体が節参照BY ORDER、複数のテーブルに関連付けられている場合は、ソートを行うために、インデックスを使用することができます。ORDER BY句は、そうでない場合は、MySQLの必要性は、ソート操作を実行するために、インデックスの最も左のプレフィックスの要件を満たすために必要とされますが、ソートにインデックスを使用することはできません。
あるケースでは、最も左接頭辞のインデックスを満たしていないBY句需要ORDER、それは主要な時定数としてリストされているがあります。句をWHERE句やJOINのWHEREこれらの列の定数を指定した場合は、インデックスを構成することができます。
反転数値型の場合、格納された値;あなたは異なる方向をソートする必要を行う場合は、文字列、格納された値を反転した文字列ならば、この技術は、列の値を格納することです。時間のこの種では、最終的に欲しいソートの列方向の他からその列の異なるに取得することができます。
概要
上記の調査によると、我々はそれがインデックス作成と最適化のためにいかに重要であるか、インデックスのMySQLのデータ構造を理解し、見ることができます。根本的な詳細のいくつかを理解し、我々はむしろ盲目的に遭遇した問題に対処するために他の人々を使用するように親指の経験則やルールを推測するよりも、より多くの太字コードを動作させることができるようになります。
移動し、秀内部強度がうらやましいしないでください、神喜んで、あなたはすぐになります。
第もっと世間の注目を取得し、オーノー質問をすることができる公共の場での問題があります。
強い兄100100強制
百千百のプログラミング、インターネットと何も新たな洞察を強制しました
