MySQLはローデータとインデックスデータを別のファイルに格納します。その他のデータベースの多く(ほとんど)は、ローデータとインデックスデータが同じファイルに混在しています。現在の非常に多くのシステムで MySQL の選択のほうが優れていると確信しています。
行データの格納方法には、各カラムの情報を独立した領域に格納する方法もあります(例: SDBM、Focus など)。これは、複数のカラムにアクセスするすべてのクエリでパフォーマンスに影響を及ぼします。パフォーマンスは複数のコラムへのアクセスを開始するとただちに低速化するため、このようなモデルは汎用データベースには適さないと確信しています。
一般的にインデックスとデータが一緒に格納されている場合も多くあります(Oracle、Sybase などの場合)。この場合は、レコード情報をインデックスのリーフページで検索します。このレイアウトで優れている点は、多くの場合インデックスのキャッシュ方法次第でディスクの読み取りを節約できることにあります。このレイアウトの欠点は以下のとおりです。
データの取得時にインデックス全体を読み取る必要があるため、テーブルスキャンの速度が大幅に下がる。
クエリでデータを取り出す際にインデックステーブルのみの使用ができない。
ノードからインデックスを複製する必要があるため(レコードはノードに格納できないことによる)、大量の領域が消費される。
削除があるとテーブルの速度が次第に低下する(通常、削除ではノードのインデックスが更新されないため)。
インデックスデータのみのキャッシュが困難である。