第5章：高パフォーマンス・インデックスを作成します（上）

インデックスはすぐにレコードを検索するために使用されるデータ構造のストレージエンジンで、これはインデックスの基本的な機能である。ではMySQLはまた、「キー、キー」と呼ばれる。最終的に良好なパフォーマンス指標。つまり、インデックスクエリのパフォーマンスを簡単に増加し、最適化することができます数桁。

1.インデックス・ベース

select first_name from actor where actor_id = 5;

上記のクエリを実行します。インデックスの値によってMySQLの最初の外観をして、データを含む行の値を返す：ACTOR_ID列に索引がある場合、MySQLは言うことですつまり、5列ACTOR_ID見つけるためにインデックスを使用します。

最も左接頭辞列のインデックスは、MySQLはインデックスの唯一の効率的な利用をすることができ、列の順序は非常に重要であり、1つ以上の列が含まれていてもよいです

1.1のタイプインデックス

記憶層によって達成MySQLのインデックス、ストレージエンジンの異なる実装

MySQLはインデックスをサポートしています。

B-Treeインデックス
- BツリーインデックスBツリーデータ構造は、データを格納するのに使用します
- B InnoDBは+ Treeインデックスが実装に使用しました
- データアクセスの速度を向上させるために、代わりにフルテーブルスキャンのインデックスのルートから検索を開始することにより、ストレージエンジン
- B-Treeインデックスは順次ので、ルックデータのために、列に格納されて編成します
- あなたは、クエリのタイプBツリーインデックスを使用することができます。
  - マッチやインデックスのすべての列：すべての値が一致
  - 最も左のプレフィックスマッチは：最初の列のインデックスを一致させます
  - 列プレフィックス一致：列値の先頭にマッチ
  - マッチ値の範囲
  - 第二列の範囲に一致する、最初の完全一致：と列の一致は、正確列の範囲と一致します
  - アクセスのみインデックス列
- B-treeが操作順に使用することができます
- そこInnoDBの適応ハッシュインデックスは、Bツリーに基づいてハッシュインデックスを作成することができます
- Bツリーの制限：
  - 唯一の左端の列のインデックスから始まるに適用して下さい
  - 列インデックスをスキップすることはできません、このようなインデックスは、最初の3つだけが見つからない、3です
  - クエリーが列範囲クエリを持っている場合、それは、索引チューニングの検索を使用するすべての列の右にすることはできません
ハッシュインデックス：ハッシュテーブルに基づいて、唯一の完全一致では、すべてのインデックス列が有効であることが照会します。
- いくつかのシナリオでは、より適切なハッシュインデックスのパフォーマンスはより明白です
- インデックス内のハッシュインデックス、ハッシュ・テーブルのすべてのデータ行へのポインタを格納するハッシュコードを記憶されています。
- ハッシュ値が複数の列と同じである場合、インデックスはに同じハッシュエントリにリンクされたリスト内の複数のレコードが格納されます
- 単に省スペース、簡単に見に対応するハッシュ値を保存します
- ハッシュの制限
  - 指数の値がライン（性能に小さな影響）を読み取る回避するために使用することができません
  - インデックス値の順序に従って並べ替えに使用することはできないではありません
  - これは、部分的に一致する索引列をサポートしていません。
  - 同等の比較をサポートし、範囲を見つけることができないだけ
  - あまりにも多くのハッシュ衝突が増加し、インデックスのメンテナンスコストにつながります
- カスタムハッシュインデックス：Bツリーに基づいシャムハッシュ、カスタムハッシュ関数を使用して、キーのルックアップハッシュインデックス・ルックアップを使用している場合にのみ、where句の後
空間データのインデックス
フルテキストインデックス
他の

2.インデックスの利点

これは、スキャンするデータ・サーバの量を減らします
避けてソートや一時テーブル
ランダムI / Oは、シーケンシャルI / Oとなり

すぐにインデックスを支払っメリットよりも大きい、レコードのメンテナンスコストを見つける助けにのみ、ストレージエンジンのインデックス、インデックスは貴重です

3.高性能インデックス戦略

3.1独立したコラム

「独立した列」：列は表現インデックスの一部であること、また関数のパラメータであることはできません。

3.2プリフィックス索引と選択指数

インデックスが長すぎる缶インデックスを開始する文字の一部だけである場合は、あなたがスペースを節約し、効率を向上させるが、選択性指数を削減することができます。
選択指数：合計の比は、データ・テーブル・インデックス値とTの数を記録繰返さない：1 / T 1の間
- 高い選択指数、クエリの高効率化、MySQLの9行以上出て高い選択性フィルタ。
- 一般的には、列のプレフィックス選択性が十分に高いです

以上の3.3カラムインデックス

複数の列に独立した別のインデックスの確立は、ほとんどの場合でのMySQLのクエリのパフォーマンスを向上させることはできません。

組み合わせ指数は、より頻繁にテーブルとさらに悪い上に構築されたインデックスを記述する際の最適化戦略は、時には結果です：

サーバがある場合、複数のインデックスが交差するマルチカラムインデックスの必要性を示唆し、操作（複数の条件）、すべての列が含まれている操作を行います
複合操作を行うには、サーバは、複数のインデックス（または複数の条件を）発生した場合、一般的にキャッシュアルゴリズムにマージするCPUとメモリの必要性の多くを必要とします。

あなたはインデックスが合併を説明表示された場合、あなたがhiはすでに最適であるかどうかを決定するためにクエリやテーブル構造を確認する必要があり、あるいはいくつかの点で、あなたはオフにしたり、インデックスを無視することができます。

3.4インデックス列の適切な順序を選択

正しい順序は、インデックスを照会するために使用に依存し、また常に見つけるための時間であるインデックス列の右の順に左から、並べ替えとグループ化のニーズを満たす方法を検討する必要があります。
並べ替えとグループ化の選択を考慮せずに、通常の優れた実践の最前線で最高のことが、唯一の場所、クエリ制限されます。
しかし、性能、すなわち値の分布、カラムの選択性指数にのみ依存し、また、特定の値のクエリ条件に関連していません。