MyISAMストレージエンジン
B +ツリーインデックス構造として使用されるのMyISAMエンジンは、リーフ・ノードは、データ・レコードのアドレスデータフィールドに格納されます。図は、MyISAMテーブルインデックスの概略図である：
ここでは3つのテーブルの合計を提供し、我々はのCol1主キーをとる、一次インデックスは、概略的に図MyISAMテーブル（プライマリキー）です。これは、アドレスのみのデータレコードの保存のMyISAMインデックスファイルを見ることができます。MyISAMテーブルでは、メインインデックスと構造の違い無しセカンダリインデックス（セカンダリキー）が、主インデックスキー要求はユニークであり、補助キーインデックスが繰り返されてもよいです。：私たちはCol2に上のセカンダリインデックスを構築した場合、このような構造の指標を以下に示す。
また、B +ツリーで、データフィールドに格納されたアドレスのデータが記録されます。キーが存在する指定された場合従って、B +ツリー検索インデックスに応じて、第1探索アルゴリズムアルゴリズムのMyISAMインデックス検索は、取り出し、そのデータフィールドの値は、その後、アドレスデータフィールドの値は、対応するデータレコードを読み出します。
MyISAMのインデックスモードもそうInnoDBがインデックスをクラスタ化区別するために呼ばれる理由は、「非クラスタ化」と呼ばれています。
InnoDBストレージエンジン
がInnoDBはまた、異なるMyISAMテーブルと、B +ツリーインデックス構造が、特定の実装方式として使用します。
最初の大きな違いは、InnoDBのデータファイル自体はインデックスファイルであるということです。上記、MyISAMのインデックスファイルとデータファイルから分離されている既知の、データレコードに格納されたインデックスファイルのアドレスのみ。InnoDBのテーブルデータファイル自体では、組織の押し付けB + Treeインデックス構造で、このツリーのリーフノードデータフィールドには、完全なデータの記録を保持しています。InnoDBのテーブルデータファイル自体がメインのインデックスであるように、このインデックスは、キーデータテーブルの主キーです。
InnoDBは、メインインデックス（データファイル）の模式図であり、あなたはリーフノードは完全なデータ・レコードが含まれて見ることができます。このインデックスは、クラスタ化インデックスと呼ばれています。InnoDBが必要ですので、主キーは一意のデータレコードを識別するとして何がある場合のInnoDBデータファイル自体Yaoan主キーの集合なので、テーブルには、明示的に指定しない場合は、MySQLのシステムは自動的に列を選択します（MyISAMテーブルができない）、主キーを持っていない必要がありますこの列は、MySQLは自動的にこのフィールドには、長整数型として、長さは6バイトで、主キーInnoDBテーブルとして隠されたフィールドを生成します。
第2の相違点は、MyISAMテーブルインデックスInnoDBの二次インデックスフィールドデータを格納するレコードを主キー値の代わりに、アドレスに対応するということです。換言すれば、全てのセカンダリインデックスのInnoDBは、プライマリキーのデータフィールドとして挙げられます。たとえば、以下の図COL3の2次索引の定義：
比較基準として、ASCIIコードで、ここで英語の文字。この実装クラスタ化インデックスは、検索高効率の主キーを押して行いますが、セカンダリインデックスの検索インデックスは二回取得する必要があります：最初の補助主キーインデックスが取得され、取得、および、取得したレコードを取得するために、主キーにプライマリ・インデックスを使用します。
すべてのセカンダリインデックスがメイン参照されているので、たとえば、私たちが達成するためのインデックスの後のInnoDBを知って、適切な使用のためのインデックス異なるストレージエンジンの実装および最適化インデックスは非常に有用である学び、主キーとして長いフィールドの使用を推奨しない理由は簡単ですインデックスは、長いメインインデックスがセカンダリインデックスが大きくなりすぎるようになります。別の例として、非単調なフィールドInnoDB内の主キーではない良いアイデアとしてのInnoDBデータファイル自体はB +木であるため、非単調なプライマリキーは+ツリー特性Bを維持するために、新たな記録データファイルの挿入になります頻繁分割は非常に非効率的、調整、および使用の自動インクリメントフィールドが主キーとして良い選択です。
InnoDBは主キーをインクリメント
InnoDBのクラスタ化インデックスを使用して、実施のInnoDBインデックス上述、データ自体は、メインインデックス（B +ツリー）リーフノードにレコードに格納されています。これは、MySQLの適切なノードに挿入され、その主キーによれば、新しいレコードが挿入されてあるので、いつでも、主キーシーケンスを記憶されたレコードの各データノードのリーフ（メモリページまたはディスク・ページのサイズ）内で同じ必要ページの負荷率が（デフォルト15/16としてのInnoDB）に達した場合と場所は、新しいページ（ノード）が開かれています。
テーブルがインクリメント主キー、新しいレコードが挿入されるたびに使用している場合、それは、インデックスノード、充填されたとき、それは自動的に新しいページが開かれるの現在位置に加え、その後のシーケンスを記録します。下図のように：
これは、次近似を埋めるために、コンパクトなインデックス構造を形成することになります。それぞれが、挿入されている既存のデータを移動するために、効率が非常に高いので、それはインデックスを維持する上で多くのオーバーヘッドを追加しません必要はありませんので。
（などのID番号または学生番号、あれば）非インクリメントプライマリキー場合は、ランダムな挿入に似各プライマリキー値ので、新しいレコードが既存のインデックスページに挿入されるたびに、特定の中間位置を持っている必要があります。
この時点で、MySQLのも目的のページがディスクに書き戻され、キャッシュからクリアされている可能性があり、適切な位置や動きのデータに新しいレコードを注文しなければならなかった、あなたは多くのオーバーヘッドを追加し、ディスクからリードバックする必要があります頻繁に移動しながら、ページング操作は、破片の多くを引き起こしたコンパクトな索引構造ではなかった、フォローアップは、ページの最適化テーブルによって最適化し、フィルテーブルを再構築しなければなりませんでした。
可能であればしたがって、InnoDBの上のエネルギー自給プライマリキーフィールドに設計する必要があります。
