まず、どのようなインデックスですか？
MySQLのインデックスは、効率的にデータのデータ構造を得るのを助けることです。
第二に、インデックスはあなたが行うことができますか？
インデックスは、重大である場合は特に、より多くのテーブル内のデータの量、パフォーマンスの指標より重要な効果。インデックスは、簡単に、一般的に、我々は大幅にクエリの効率を向上させることができるということです、桁違いにクエリのパフォーマンスを向上させることができます。
第三に、分類の指標？
図1は、ストレージ構造が分割される：Bツリーインデックス（B木又はB +ツリーインデックス）、ハッシュインデックス、フルインデックスフルテキストインデックス、R-Treeインデックス。インデックスが形式で格納されたときに保存され、本明細書に記載の、
図2に示すように、アプリケーション・レベルから点へ：一般インデックスだけインデックス、複合インデックス
図3に示すように、キーデータ（インデックス）シーケンス関係の論理 - 物理順序に従って：クラスタ化インデックス、非クラスタ化インデックス。
通常、一般的には、アプリケーションレベルの部門を参照するインデックスのタイプについて話しています。
電話カテゴリのように：Android携帯電話、IOS電話とHuawei社の携帯電話、アップルの携帯電話、OPPO携帯電話のように。
共通のインデックスは：すなわち、単一の列のインデックスが含まれ、テーブルには、複数の独立したインデックスを持つことができます
インデックスのみ：索引列の値は一意であるが、自由な値を許可する必要があります
指数：組成の複数列インデックス値、具体的にはコンビナトリアル探索のためには、効率は、結合率よりも大きいです
クラスタ化インデックス（クラスタ化インデックス）：ていない単一のインデックス・タイプが、データ記憶装置。実装の詳細に依存して、InnoDBはインデックスが実際には同じ構造（技術B +ツリー）におけるB-Treeインデックスとデータラインに格納されているクラスタ化。
非クラスタ化インデックス：クラスタ化インデックスは、非クラスタ化インデックスではありません
第四に、基本となるインデックスの実装
MySQLのInnoDBのデフォルトストレージエンジンのみ明示的にサポートBツリー頻繁にアクセスされるテーブルのインデックス（B +ツリーは技術的である）、InnoDBの透過確立適応ハッシュインデックス、Bツリーインデックスに基づいて確立された、すなわちハッシュインデックス大幅に検索効率を向上させることができ、クライアントは、透明手に負えない、暗黙的です。
Hash索引
ハッシュテーブルの実装に基づいて、唯一の正確なクエリインデックスは、ストレージエンジンは、すべてのインデックス列のハッシュコード（ハッシュコード）について算出されたデータの各行のすべての列に有効であることが一致し、すべてのハッシュインデックスハッシュコードストレージインデックスに、インデックステーブル中の各データ列のポインタを保持しながら。
B-Treeインデックス（B +ツリーを使用してMySQL）
エンジンがもはやデータを取得するためにフルテーブルスキャンを格納する必要がないので、Bツリーは、データアクセス速度を高速化することができ、データは、様々なノード間に分散します。
B + Treeインデックス
Bツリーインデックスデータベースの改良版も使用インデックス構造を格納しています。リーフノード上のデータ、および順次アクセス・ポインタを増加させ、隣接するリーフノードのアドレスに各リーフノード点。範囲検索、Bツリーを見つけるために比較した場合にのみ2つのノードが、横断することができます。B +ツリーより高い効率と比較して、Bツリーとノードのすべてを取得する必要があり、。
例：ID主キー、あなたが学生のテーブルを持っていると言います
| ID | 名 | お誕生日 |
|---|---|---|
| 1 | トム | 1996-01-01 |
| 2 | ジャン | 1996年1月4日 |
| 3 | レイ | 1996年1月8日 |
| 4 | マイケル | 1996年1月10日 |
| 5 | ジャック | 1996年1月13日 |
| 6 | スティーブン | 1996年1月23日 |
| 7 | リリー | 1996年1月25日 |
MyISAMエンジンに実装（セカンダリインデックスにより達成されます）
InnoDBの実装
第五に、なぜ代わりにハッシュ、バイナリツリー、赤黒木のB +ツリーを使用して、デフォルトのインデックス構造、？
Bツリー：Bツリーので、データはリーフノードと非リーフノードに関係なく保存され、これは（また、ファンアウトとして知られている情報の一部）より少ない、少なくともポインタ状況を保存するために保存することができ、非リーフノードにおける指の数につながっています大量のデータは、のみ、クエリのパフォーマンスが低いIOオペレーション増加をもたらす、木の高さを増加させることができます。
ハッシュ：あなたはすぐに見つけることができますが、ないため、IO高い複雑さはありませんが。
バイナリツリー：IOとコスト高に関連するデータと非常に不均一なツリーではなく、自己バランス、検索効率（木の高さ）。
赤黒木：木の高さは、データ量が増加するにつれて増加、IOのコストが高いです。
第六に、なぜ公式は、主キー索引としての自己成長を使用することをお勧め？
结合B+Tree的特点，自增主键是连续的，在插入过程中尽量减少页分裂，即使要进行页分裂，也只会分裂很少一部分。并且能减少数据的移动，每次插入都是插入到最后。总之就是减少分裂和移动的频率。
插入连续的数据：
插入非连续的数据
七、简单总结下
1、MySQL使用B+Tree作为索引数据结构。
2、B+Tree在新增数据时，会根据索引指定列的值对旧的B+Tree做调整。
3、从物理存储结构上说，B-Tree和B+Tree都以页(4K)来划分节点的大小，但是由于B+Tree中中间节点不存储数据，因此B+Tree能够在同样大小的节点中，存储更多的key，提高查找效率。
4、影响MySQL查找性能的主要还是磁盘IO次数，大部分是磁头移动到指定磁道的时间花费。
5、MyISAM存储引擎下索引和数据存储是分离的，InnoDB索引和数据存储在一起。
6、InnoDB存储引擎下索引的实现，(辅助索引)全部是依赖于主索引建立的(辅助索引中叶子结点存储的并不是数据的地址，还是主索引的值，因此，所有依赖于辅助索引的都是先根据辅助索引查到主索引，再根据主索引查数据的地址)。
7、由于InnoDB索引的特性，因此如果主索引不是自增的(id作主键)，那么每次插入新的数据，都很可能对B+Tree的主索引进行重整，影响性能。因此，尽量以自增id作为InnoDB的主索引。
文章转自https://mp.weixin.qq.com/s/gNmWY8ob-QN6ZVF7e-71cA，微信公众号-程序员的私房菜