MySQL は .frm
ファイル内のテーブルのデータ
ディレクトリ情報をデータベース
ディレクトリに格納します。これは全ての MySQL
ストレージ
エンジンに言える事です。しかし全ての
InnoDB
テーブルもテーブルスペースの内側にある
InnoDB
内部データ
ディレクトリ内にそれ自体のエントリを持っています。MySQL
がテーブルやデータベースをドロップする時、それは
.frm
ファイルと
InnoDB
データ
ディレクトリ内の対応するエントリの両方を削除する必要があります。これが、単に
.frm
ファイルを移動するだけで
InnoDB
テーブルをデータベース間で移動する事ができない理由です。
全ての InnoDB
テーブルは、行のデータが格納されている
clustered index
と呼ばれる特別なインデックスを持っています。もし
PRIMARY KEY
をテーブル上で定義したら、主キーのインデックスは集合インデックスになります。
もしテーブルに PRIMARY KEY
を定義しなければ、MySQL は主キーとして
NOT NULL
カラムだけを持つ最初の
UNIQUE
インデックスを選択し、InnoDB
がそれを集合インデックスとして利用します。もしテーブル内にそのようなインデックスがなければ、InnoDB
は、行が InnoDB
がそのようなテーブル内の行に割り当てた行 ID
によってオーダされる集合インデックスを内部的に生成します。行
ID
は、新しい行が挿入されると単調に増加する6バイトのフィールドです。従って、行
ID
によってオーダされた行は物理的に挿入順になっています。
行データはインデックス サーチが導く物と同じページ上にあるので、集合インデックスを通しての行へのアクセスは速いです。テーブルが大きいと、集合インデックス構造は従来の解決法と比較して、ディスク I/O を節約する事が多いです。(多くのデータベース システムでは、データの格納はインデックス レコードからの別のページを利用しています。)
InnoDB
では、非集合インデックス(セカンダリ
インデックスとも呼ばれる)内のレコードは、行に対して主キー値も含んでいます。InnoDB
は、この主キー値を集合インデックスから行を検索するのに利用します。もし主キーが長いと、セカンダリ
インデックスがより多くの領域を利用する事に注意して下さい。
InnoDB
は、短い方の文字列の残りの長さが領域で詰められたかのように扱われるように、長さの異なる
CHAR
と VARCHAR
文字列を比較します