インデックスではない列は、インデックスとともにディスク上でソートされていますか？

インデックスではないカラムは、MySQL、MyISAM、InnoDBで、インデックスと一緒にディスク上でソートされますか？

私が書き始めた誤った考え：

それらは索引付けされていないので、おそらくそうではないと思います。それらがソートされた場合、それらはインデックスであることを意味します。

すべてのインデックス列が独自のコンテンツの順序で並べ替えられているため、これは正しくありませんが、対応するインデックスを持つすべての行（または一部の列のみ）の順序付けについて質問しています。

説明すると、これは、インデックスによって並べて並んでいる行の範囲をより速く選択するのに役立ちます。たとえば、select * where id >1000 and id<2000（MySQL構文に誤りがある可能性があり、よくわからない）場合、おそらく1000から2000までのセルが物理ディスク上に残っているため、id列自体をディスクからすばやく読み取ることができます。 。ただし、ID 1000から2000に対応する他の列の内容は、物理ディスク上の別の場所に書き込まれる場合があります。それらもソートされている場合、より速く読み取られます。おそらく、MySQLはそのような操作のパフォーマンスのために、物理ディスク上の列を自動的にソートします。

それらは他のタイプのデータベース（PostgreSQLなど）でソートされていますか？

12月27日：2つの回答から、クラスター化インデックス/主キーがある場合、単純な行自体が物理ディスク上でソートされていない可能性があります（私が思ったように）、クラスター化インデックスでさえもソートされていない、それがbツリーである場合、私はbツリーについて読み、そのノードが、私が理解しているように、ディスク上のランダムな場所に留まっていることを確認しました。

場合によってはソートされることがあります。の並べ替えインデックスが通常と呼ばれるクラスタリング・キー。その場合は、テーブル全体がそのようなインデックス内に格納されます（通常、ある種のBツリー構造で）。

その他の場合、テーブル構造は ヒープ、行はそのまま格納され、データブロック内のリーフの「穴」を削除します。これらの穴は後で新しい行で埋められるため、「挿入順序」も保持されません。

MyISAMはヒープを使用します構造を各行はデータファイルへのオフセット（配列インデックスの種類）によって識別されます。各インデックスには、各行のインデックス付きの列が含まれ、適切な順序で並べ替えられ、実際の行を見つけるためのオフセット番号が付けられます。つまり、任意のインデックスで行にアクセスするということは、インデックス（Bツリー）で正しいノードを見つけ、データファイルから正しいオフセットを読み取ることを意味します（ディスクの別の部分へのランダムシークが発生する可能性があります） ）。

InnoDBは、 主キーます（または、何も定義されていない場合、最初にnull以外の一意キーが使用されるか、内部自動インクリメント列が追加されるため、行は常に何らかの方法でソートされます）。そのような場合、主キーによるアクセスは「直接」であり、適切な値が見つかると、行全体が手元にあり、2回目の読み取りを行う必要はありません。一方、セカンダリインデックスはMyISAMのようにオフセットを格納できません（Bツリー自体が動的に再調整されるため、特定の行のオフセットはいつでも変更される可能性があります）。代わりに、行の主キー値を格納します。セカンダリキーによるアクセスは、InnoDBでの2つのBツリー検索を意味します。

MS SQL Serverには、主キー（または別のインデックス）をクラスター化または非クラスター化するオプションが用意されているため、ヒープから選択できます。（インデックスがクラスター化されていない）とツリー構造（1つのインデックスがクラスター化されている）。他のすべての非クラスター化インデックスは、ヒープの場合は特別な（RowID）値を、CIの場合は行のクラスター化されたキー値を格納します。

PostgreSQLはヒープテーブルのみを使用しますが、必要に応じてインデックスによってそれらを並べ替えることができます（トリガーする必要があるため、アクションの後に行が並べ替えられますが、テーブルにさらに書き込むと、その順序が再び壊れる可能性があります）。

TokuDB（サードパーティのMySQL / MariaDBエンジン）は、1つのテーブルで複数のクラスタリングキーを使用できます。事実上、テーブルの複数のコピーを維持し、それぞれ異なる方法でソートします。書き込みにはペナルティがありますが、TokuDBはフラクタルインデックスと呼ばれるものを使用すると主張しているため、ペナルティはかなり小さくなります。

一部のクエリでその機能を使用する必要がある場合は、カバリングインデックスを作成することでそれを「エミュレート」できます。これにより、クエリに必要な列をいつでも正しい順序で使用できますが、（ ）インデックス内のテーブル。

一般に、データベースの短くて単純な答えは次のとおりです。いいえ、テーブル内の行の物理的な順序は、通常、そのテーブルの一部のインデックスと同じではありません。

一般に（そうでない特別な場合があるので、一般的に言っています）テーブルとインデックスは、ディスク上の2つの異なる物理構造です。従来のRDBMはデータを格納するため、1つのテーブル行（columnではなく）の値がディスク上で隣同士に配置されます。行自体は特定の順序で格納されません。一方、インデックスエントリは順番に保存されます。典型的なBツリーインデックスには、インデックス付きの列のソートされた値（他の列ではなく！）と、前に述べたように、ディスク上の個別の物理構造であるテーブル内の行全体の場所へのポインタが含まれています。

そうは言っても、特別な場合があります。たとえば、MySQLのInnoDBは実際のデータ行をインデックスのような構造で格納します。このような「インデックステーブル」に行を配置するためのインデックスは、通常、テーブルの主キーです。このようなインデックスは、クラスター化インデックスと呼ばれます。ただし、もちろん、InnoDBテーブルには他のインデックスがあり、それらのインデックスでの行（つまり、それぞれのインデックスに含まれる行列）の順序は、テーブル自体の行の順序とは関係ありません。