どのような指標がありますか？
効率的な運用のためのビルドMySQLのMySQLのインデックスが非常に重要であり、指数が大幅にMySQLのの検索速度を向上させることができます。
合理的な設計と使用MySQLのインデックスがランボルギーニであれば、例えば、インデックスのないMySQLの設計および使用は三輪車ではありませんがあります。
サブインデックス別指数と組合せ指数。別のインデックス、すなわち単一の列インデックスを含む、テーブルは、複数の個別のインデックスを持つことができ、これは複合インデックスではありません。組み合わせ指数、すなわち、複数の列を含むインデックス。
あなたは、インデックスを作成するときは、必ずインデックスが（通常はWHERE句の条件など）SQLクエリアプリケーション内の条件であることを確認する必要があります。
実際には、インデックスはまた、エンティティテーブルを記録するために主キーとインデックスフィールド、及びポイントを保持するテーブルです。
上記のインデックスを使用することの利点について話しているが、インデックスのあまり使用は乱用につながります。そのため、インデックスもその欠点があります。それは、テーブルの更新速度が低下する一方、インデックスが大幅なテーブルのINSERT、UPDATE、およびDELETEなど、クエリの速度を増加したものの。あなたがテーブルを更新する場合、MySQLはデータを保存するだけでなく、インデックスファイルについて保存することだけではありませんので。
インデックスファイルのインデックスは、ディスクスペースを占めています。
カテゴリーインデックス
まず、分類リストされたプロパティに応じて
別のインデックス
作成した表内の単一列フィールドへのインデックス
共同インデックス
作成したインデックス複数の列フィールドの組み合わせテーブルに、左端の費用収益対応の原則以下の効果を取るために左のフィールドからのクエリー配列内のインデックスを使用しています。
共同インデックスと別のインデックスも含まれています：
一般的な指標
非主キー、列の非ユニークインデックス
主キー索引
インデックスに自動的に生成されたテーブルの主キーに基づいて、主キーを定義するテーブルにない場合は、満たさない場合は、テーブル、（テーブル名から選択_rowidを通して見ることができる）その主キーとして一意のインデックスを成形し、非空であるかどうかを探します暗黙のうちに主キーとして生成されたROWID（直接見られません）
インデックスのみ
生成されたヌル値を許可する、ユニーク索引列テーブルに基づいて、
フルテキストインデックス
そのような％キーワード％などのテキストの大規模なクラスとして、情報を見つけるために全体の本や記事全体の内容のいずれかのデータベースに格納され、フルテキストインデックスに比べて効率の一般的な指標は非常に低いです。
第二に、データ構造分類に従って
B +ツリーインデックス
B +ツリーが探索木バランスマルチプレクサの平衡二分木に基づいて、すべてのレコードがリーフノードの順に格納され、各リーフノードに直接リンクされたリストによって接続されています。そして、ツリーbはそれが異なります。
非リーフノードは、鍵情報のみを保存します。
これは、すべてのリーフノード間のポインタのチェーンを持っています。
データレコードは、リーフノードに格納されています。
ハッシュインデックス
達成するために、インデックスハッシュテーブル構造に基づいて、MySQLの専用メモリ/ヒープとNDBストレージエンジンのサポート。
InnoDBエンジンは、適応ハッシュインデックスをサポートしていますが、データベース自体を作成するために使用され、かつ任意に定義することはできません。セカンダリインデックスが頻繁にアクセスされると、自動的に適応ハッシュインデックスを作成します。
SHOW ENGINE INNODB STATUSコマンドは、適応ハッシュインデックスの使用を表示します。
オープン適応ハッシュインデックスかどうかを確認するために「％のAPの％のhash_index」LIKEコマンドSHOW変数を設定します。
コントラスト：
ハッシュインデックスは、ハッシュ値を比較することであるので、ハッシュインデックスは同等の検索範囲を見つけることができないことができ
ハッシュインデックスはソートすることができません。同じ理由
左端の費用収益対応の原則をサポートしていない、ハッシュ値のマージ一緒に計算する際に複合インデックス
高い検索効率のハッシュインデックスが一度に配置することができるが、ハッシュ衝突が多数発生した場合、リストが長くなり、効率の良いハッシュインデックスB +ツリーとしてありません
あなたは合計数を取得する必要がある場合ので、ハッシュ衝突の問題のため、いつでもハッシュインデックスはテーブルスキャンを回避することはできません
T-treeインデックス
R-treeインデックス
第三に、ストレージ構造分類に従って
クラスタ化インデックス（クラスタ化インデックス）
InnoDBのクラスタ化インデックスは、実際にはB木を同時にインデックスとデータの行全体を格納する同じ構造で、クエリデータクエリは行インデックスを介して直接取得するようにしてもよいです。
クラスタ化インデックスは、ハードディスク上のデータの物理的な順序で別のインデックス・タイプが、データを記憶するようにして、クラスタ化インデックスではありません。
MySQLでは、クラスタ化インデックスは、各テーブルは一つだけクラスタ化インデックス（必ずしも他のデータベース）が含まれ、主キーを持つ通常同義です。
セカンダリインデックス（非クラスタ化インデックス、二次索引、二次索引）
B木のリーフノードでの非クラスタ化インデックスおよび主キー索引列を取り揃えています。クエリがインデックス列内にない場合、その主キーでのみ見ることができ、あなたもテーブルクエリにアクションクエリ、クラスタ化インデックスバックを必要としています。
クラスタード・インデックスの利点：
一緒のような関連データ、保存することができます：実装する電子メールを、ユーザーIDに基づいてデータを収集することができるので、少量のデータだけをディスクページから読んでクラスタ化インデックスを使用していない場合、ユーザーは、すべてのメールを取得することができます、各メッセージには、ディスクIOを引き起こす可能性があります。
これより高速なデータアクセス、クラスタ化インデックスと同じBTREEに格納されたインデックスデータを、より早く通常クラスタ化インデックスから非クラスタ化インデックスで見つけるよりも、データを取得します。
プライマリキーノードページに直接使用することができるカバーするインデックススキャンのクエリを使用してください。
クラスタ化インデックスの欠点：
クラスタ化されたデータはIO集約型アプリケーションのパフォーマンスを最大化するため、これにメモリ内のすべてのデータが、訪問の順番はそれほど重要ではなかった場合は、クラスタ化インデックスも何の利点ません
挿入速度は、主キーの順序で挿入、挿入の順に大きく依存しているのInnoDBテーブルに負荷データに最速の方法であるが、それは主キーの順序でロードされたデータでない場合には、ロード後の最適化テーブルコマンドを使用することが好ましい完全な再編成表であります。
それはInnoDBが新しい場所に移動するように各行を更新する強制するため、クラスタ化インデックス列が高価更新。
クラスタ化された新しい行挿入テーブルのインデックス、または主キーは行を移動させる必要のある結果に基づいて更新されたときに、主キーは行の中に挿入されなければならない場合、問題のページ分割に直面する可能性は、この行にフルページを要求、ストレージエンジンは、これはページ分割操作で、銀行に対応するために、2つのページにページを分割し、分割は、ページテーブルは、より多くのディスク領域を占める結果となります。
クラスタ化インデックスは、特にラインまばらな中で、スローダウン、またはページ分割は、データストレージ不連続な時間が発生するため、スキャン、フルテーブルをもたらすことができます。
セカンダリインデックスのリーフノードに主キー列の参照列が含まれているため、二次インデックスは、以前に考えられていたよりも大きくてもよいです。
セカンダリインデックスアクセスは、二つのインデックス検索、代わりのいずれかが必要です。
