10

データを含むテーブル列があり、この列にインデックスを作成する場合、インデックスは列自体と同じ量のディスクスペースを使用しますか？

bツリーが実際にリーフノードに列データのコピーを保持しているかどうか、または何らかの形でそれを指しているかどうかを理解しようとしているので、興味があります。

これが「JavaがXMLに取って代わるのか」という場合は申し訳ありません。親切な質問。

アップデート：

単一のGUID列を持つインデックスなしのテーブルを作成し、100万行を追加-26MB

主キー（クラスター化インデックス）を持つ同じテーブル-25MB（さらに少ない！）、インデックスサイズ-176KB

一意のキーを持つ同じテーブル（非クラスター化インデックス）-26MB、インデックスサイズ-27MB

したがって、非クラスター化インデックスのみがデータ自体と同じスペースを使用します。

すべての測定はSQLServer2005で行われました。

4

3 に答える 3

4

Bツリーはテーブル内の行を指しますが、Bツリー自体はまだディスク上にいくらかのスペースを取ります。

一部のデータベースには、メインインデックスとデータを埋め込む特別なテーブルがあります。Oracleでは、IOT（インデックス編成テーブル）と呼ばれます。

通常のテーブルの各行は、Bツリーが行を識別するために使用する内部ID（ただしデータベース固有）によって識別できます。Oracleでは、これはと呼ばれ、次のrowidようになりますAAAAECAABAAAAgiAAA:)

データを含むテーブル列があり、この列にインデックスを作成する場合、インデックスは列自体と同じ量のディスクスペースを使用しますか？

基本的なBツリーでは、列のアイテムの数と同じ数のノードがあります。

考えてみてください1,2,3,4：

    1 
  / 
2
   \ 3 
      \ 4

正確なスペースはまだ少し異なる可能性があり（ノード間のリンクを格納する必要があるため、インデックスはおそらく少し大きくなります、完全にバランスが取れていない可能性がありますなど）、データベースは最適化を使用してインデックスの一部を圧縮できると思います。ただし、インデックスと列データの大きさの順序は同じである必要があります。

于 2010-03-05T09:23:54.660 に答える
2

私はそれがかなりDBに依存しているとほぼ確信していますが、一般的に–ええ、それらは追加のスペースを取ります。これは、次の2つの理由で発生します。

  1. このようにして、BTREEリーフのデータが並べ替えられているという事実を利用できます。

  2. 必要なものを取得するために前後に探す必要がないため、ルックアップ速度の利点が得られます。

PSはmysqlサーバーをチェックしました：20GBのテーブルインデックスの場合、10GBのスペースが必要です:)

于 2010-03-05T09:26:07.437 に答える
0

この記事から判断すると、実際には、列のデータと少なくとも同じ量のスペースが必要になります（とにかくPostgreSQLでは）。この記事では、ディスクとメモリの使用量を削減するための戦略についても説明しています。

自分で確認する方法は、たとえばderby DBを使用して、100万行と1列のテーブルを作成し、サイズを確認し、列にインデックスを作成して、サイズをもう一度確認することです。10〜15分かかる場合は、結果をお知らせください。:)

于 2010-03-05T09:33:55.847 に答える