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 文字列を比較します