web-dev-qa-db-ja.com

すべてのリレーショナルDBMSは、デフォルトで主キーに基づくクラスター化インデックスにテーブルタプルを格納しますか？

だから私はMySQL innoDBを読んでいました、それは明らかに主キーに基づいてクラスター化されたインデックス（b + tree）にデフォルトでテーブルデータを保存し、タプルはそのb + treeのリーフにあります

https://blog.jcole.us/2013/01/10/btree-index-structures-in-innodb/

PostgreSQL、Oracle、SQLサーバー、SQLiteなどの有名なリレーショナルDBMSをすべて同じ方法で保存しているのでしょうか？主キーに基づいてクラスター化インデックス（b + tree）を作成し、データをツリーの葉に格納する方法

データベースの主キーのクラスター化インデックスは、基本的にB +ツリーテーブルの主キーに基づいてテーブルを格納することを意味しますか？

（これが一般的な質問である場合は申し訳ありませんが、私が言及したデータベースのそれぞれについて同じことを尋ねる4〜5の個別の質問を作成することはできません。

また、データベースがデフォルトでクラスター化を使用していない場合、ファイルがどのようにファイルを構造化するかを説明できますか？たとえば、リーフがヒープ内のある種のアドレスを指す主キーにb + treeを作成するか... ？

編集：

これまでのところ、SQLite以外のすべての回答を得ています。デフォルトでSQLiteにテーブルが実際にどのように格納されるかについて誰か情報があれば、教えてください。

sql-servermysqlpostgresqloraclesqlite
3
John P

PostgreSQL、Oracle、SQLサーバー、SQLiteなどの有名なリレーショナルDBMSはすべて同じ方法で保存しますか？主キーに基づいてクラスター化インデックス（b + tree）を作成し、データをツリーの葉に格納する方法

いいえ、すべてではありません。それらを一つずつ見てみましょう：

  • MySQL。 MySQLにはいくつかの「エンジン」があり、テーブルが使用するように定義されているエンジンに応じて、ストレージは次のようになります。

    • InnoDB：はい、説明したとおり、テーブルデータはテーブルの主キー列に基づくインデックスを持つクラスター化インデックス（およびPKが定義されていない場合は、null以外の列を持つ最初のUNIQUEインデックス、それがない場合は秘密の6バイト）内部列）。
    • MyISAM：いいえ、テーブルはヒープであり、クラスター化インデックスではありません。
    • その他のエンジン：（NBD、ブラックホール、CSVなど）いいえ、私はそれらのどれもクラスター化インデックスを使用していないと思います（おそらくNBDを除いて、わかりません）
    • TokuDB：はい。 InnoDBに似ていますが、複数のクラスター化インデックスを定義できます！

  • [〜＃〜] sql [〜＃〜]サーバー：はい 、PKを持つテーブルのデフォルトの動作は、PKでクラスター化されます。ただし、これはPKがNONCLUSTEREDであることを宣言することでオーバーライドできます。別のインデックス（PKではない）をテーブルのクラスター化インデックスとして定義することもできます。 PKがNONCLUSTEREDとして定義されていて、どのインデックスもCLUSTEREDとして定義されていない場合、テーブルはヒープです。最近のバージョンでは、3番目のオプション（クラスター化インデックスとヒープ以外）が追加されました：columnstoreは、テーブルデータを編成する別の方法です。

  • PostgreSQL：いいえ。すべてのテーブルはヒープ、ピリオドです。さまざまなタイプ（btree、hash、gin、Gist、brinなど）の追加のインデックスを作成できますが、テーブルデータはヒープに格納されます。

  • Oracle：いいえ。インデックス構成テーブル（クラスター化インデックスを表すOracleの用語）として作成されない限り、デフォルトでテーブルはヒープです。

テーブルデータの編成に関する追加の説明：

  • クラスタ化インデックス：一部の列に基づくbtee +インデックスがあり、リーフにはテーブルのデータが含まれています。

  • Heap：ヒープのbtreeインデックスはありません（PKのような他のインデックスは引き続きbtreeを使用する場合があります）。データは、レコードの順序付けされていないリストとして格納されます。新しい行が挿入されると、通常、使用可能なスペースがあるディスクページに追加されます。行は特別なPage/RowIDによって参照されます（詳細は実装によって異なり、DBMS間で確実に異なります）。そのため、他のインデックスにこの参照が含まれます。

  • Columnstore：データが行ではなく列として格納される構造のタイプ。

詳細については、各DBMSのドキュメントと以下を参照してください。- Wikipedia：Database Storage Structures - Wikipedia：Columnstore databases

11
ypercubeᵀᴹ

Linux、Unix、WindowsのDB2：いいえ

Db2では、テーブル（「ヒープ」）内の行データの場所を強制するインデックスは、一般にクラスタリングと呼ばれ、クラスタリングとは呼ばれません。これらには行データ*は含まれず、キー値のみが含まれ、テーブル内の実際の行の場所を指します。行が挿入されると、データマネージャーtriesは、同じキー値を含む他の行と一緒にページに配置します。それが不可能な場合は、通常の空きスペース検索ロジックに従って行が追加されます。その結果、時間の経過とともに、テーブルのクラスタ化係数（クラスタリングインデックスに従って順序付けられたテーブル内の行の割合）が低下します。次に、REORGコマンドを使用して、行を移動することによりクラスタリングの順序を復元します。

LUWのDb2にはデフォルトのクラスタリングインデックスはありません。 CLUSTERオプションで明示的に作成する必要があります。

Db2 for z/OS：いいえ

Db2 for LUWと同様に、クラスタリングインデックスには行データ*が含まれず、実際のテーブル行をポイントするだけです。行の挿入動作も同じです。

LUWのDb2とは対照的に、クラスタリングインデックスが明示的に宣言されていない場合、テーブルで作成された最初のインデックスが暗黙的にクラスタリングされていると見なされます。

Db2 for i：並べ替え

Db2 for iには、クラスター化（またはクラスター化）インデックスの概念はありません。ただし、インデックスを作成するときは、すべてのテーブル列をインデックスのBツリー、一部の列、またはキー列のみに追加するオプションがあります。最初のオプションは、SQL Serverスタイルのクラスター化インデックスを効果的に作成しますが、テーブルの行もテーブルの「ヒープ」に個別に格納されたままです。

*一意のインデックスにはINCLUDEオプションがあり、個別の非キー列値をインデックス自体に配置できるため、インデックスのみのアクセスが容易になります。すべての非キーテーブル列を主キーインデックスに追加するという極端なケースでは、MS SQL Serverのクラスター化インデックスと同様のインデックスになります。

3
mustaccio

SQL Serverについては、次の動作が文書化されており、4.2から2019バージョンまで引き続き有効です。

PRIMARY KEYおよびUNIQUE制約

PRIMARY KEY制約を作成すると、テーブルにクラスター化インデックスがまだ存在せず、一意の非クラスター化インデックスを指定しない場合、列に一意のクラスター化インデックスが自動的に作成されます。主キー列はNULL値を許可できません。

UNIQUE制約を作成すると、デフォルトで一意の非クラスター化インデックスが作成され、UNIQUE制約が適用されます。テーブルにクラスター化インデックスがまだ存在しない場合は、一意のクラスター化インデックスを指定できます。

制約の一部として作成されたインデックスには、制約名と同じ名前が自動的に付けられます。詳細については、PRIMARY KEY制約とUNIQUE制約を参照してください。

制約に依存しないインデックス

非クラスター化主キー制約が指定されている場合は、主キー列以外の列にクラスター化インデックスを作成できます。

これはSQL Server 2008 R2のBOLの写真です。コメントで意図されている動作が赤で示されています

enter image description here

1
sepupic