次の手順を使用して、クラスター化インデックスにデータを格納するために必要な領域の量を見積もることができます。
クラスター化インデックスのリーフ レベルにデータを格納するために使用される領域を計算します。
クラスター化インデックスのインデックス情報を格納するために使用する領域を計算します。
計算値の合計。
ステップ 1. リーフ レベルにデータを格納するために使用される領域を計算する
テーブルに存在する行の数を指定します。
Num_Rows = テーブル内の行数
固定長列と可変長列の数を指定し、そのストレージに必要なスペースを計算します。
これらの列の各グループがデータ行内で占める領域を計算します。 列のサイズは、データ型と長さの指定によって異なります。
Num_Cols = 列の合計数 (固定長および可変長)
Fixed_Data_Size = すべての固定長列の合計バイト サイズ
Num_Variable_Cols = 可変長列の数
Max_Var_Size = すべての可変長列の最大バイト サイズ
クラスター化インデックスが一意でない場合は、 uniqueifier 列を考慮します。
uniqueifier は null 許容の可変長列です。 非重複キー値を持つ行では、「nullでない」ことが保証され、サイズは4バイトになります。 この値はインデックス キーの一部であり、すべての行に一意のキー値があることを確認するために必要です。
Num_Cols = Num_Cols + 1
Num_Variable_Cols = Num_Variable_Cols + 1
Max_Var_Size = Max_Var_Size + 4
これらの変更は、すべての値が一致しないものと想定しています。
null ビットマップと呼ばれる行の一部は、列の null 値の許容を管理するために予約されています。 そのサイズを計算します。
Null_Bitmap = 2 + ((Num_Cols + 7) / 8)
前の式の整数部分のみを使用する必要があります。剰余を破棄します。
可変長データ サイズを計算します。
テーブルに可変長列がある場合は、行内の列を格納するために使用される領域の量を決定します。
Variable_Data_Size = 2 + (Num_Variable_Cols x 2) + Max_Var_Size
Max_Var_Sizeに追加されるバイト数は、各変数列を追跡するためです。 この数式では、すべての可変長列が 100% 満杯であることを前提としています。 可変長列ストレージ領域の割合が小さいと予想される場合は、その割合で Max_Var_Size 値を調整して、テーブル全体のサイズをより正確に見積もることができます。
注
定義されたテーブルの幅の合計が 8,060 バイトを超える
varchar、nvarchar、varbinary、またはsql_variantの列を組み合わせることができます。 これらの各列の長さは、varchar、varbinary、またはsql_variant列の場合は 8,000 バイト、nvarchar列の場合は 4,000 バイトの制限内に収める必要があります。 ただし、組み合わされた幅は、テーブル内の 8,060 バイトの制限を超える可能性があります。可変長列がない場合は、 Variable_Data_Size を 0 に設定します。
合計行サイズを計算します。
Row_Size = Fixed_Data_Size + Variable_Data_Size + Null_Bitmap + 4
値 4 は、データ行の行ヘッダーのオーバーヘッドです。
ページあたりの行数を計算します (1 ページあたり 8,096 バイトの空きバイト)。
Rows_Per_Page = 8096 / (Row_Size + 2)
行はページをまたがないため、ページあたりの行数は最も近い整数行に切り捨てる必要があります。 数式の値 2 は、ページのスロット配列内の行のエントリを表します。
指定された フィル ファクター に基づいて、ページあたりの予約済み空き行数を計算します。
Free_Rows_Per_Page = 8096 x ((100 - Fill_Factor) / 100) / (Row_Size + 2)
計算で使用される塗りつぶし係数は、パーセンテージではなく整数値です。 行はページをまたがないため、ページあたりの行数は最も近い整数行に切り捨てる必要があります。 充填率が高くなると、各ページに格納されるデータが増え、ページ数が少なくなります。 数式の値 2 は、ページのスロット配列内の行のエントリを表します。
すべての行を格納するために必要なページ数を計算します。
Num_Leaf_Pages = Num_Rows / (Rows_Per_Page - Free_Rows_Per_Page)
推定ページ数は、最も近い整数ページに切り上げる必要があります。
リーフ レベルにデータを格納するために必要な領域の量を計算します (1 ページあたり合計バイト数 8192)。
Leaf_space_used = 8192 x Num_Leaf_Pages
手順 2. インデックス情報の格納に使用される領域を計算する
次の手順を使用して、インデックスの上位レベルを格納するために必要な領域の量を見積もることができます。
インデックス キーに固定長列と可変長列の数を指定し、そのストレージに必要な領域を計算します。
インデックスのキー列には、固定長列と可変長列を含めることができます。 内部レベルのインデックス行のサイズを見積もるために、これらの列の各グループがインデックス行内で占める領域を計算します。 列のサイズは、データ型と長さの指定によって異なります。
Num_Key_Cols = キー列の合計数 (固定長および可変長)
Fixed_Key_Size = すべての固定長キー列の合計バイト サイズ
Num_Variable_Key_Cols = 可変長キー列の数
Max_Var_Key_Size = すべての可変長キー列の最大バイト サイズ
インデックスが一意でない場合に必要な uniqueifier を考慮します。
uniqueifier は null 値を許容する可変長の列です。 非一意のインデックス キー値を持つ行では、null 以外のサイズと 4 バイトのサイズになります。 この値はインデックス キーの一部であり、すべての行に一意のキー値があることを確認するために必要です。
Num_Key_Cols = Num_Key_Cols + 1
Num_Variable_Key_Cols = Num_Variable_Key_Cols + 1
Max_Var_Key_Size = Max_Var_Key_Size + 4
これらの変更は、すべての値が一致しないものと想定しています。
null ビットマップ サイズを計算します。
インデックス キーに null 許容列がある場合、インデックス行の一部は null ビットマップ用に予約されます。 そのサイズを計算します。
Index_Null_Bitmap = 2 + ((インデックス行の列数 + 7) / 8)
前の式の整数部分のみを使用する必要があります。 剰余を破棄します。
null 許容キー列がない場合は、 Index_Null_Bitmap を 0 に設定します。
可変長データ サイズを計算します。
インデックスに可変長列がある場合は、インデックス行内の列を格納するために使用される領域の量を決定します。
Variable_Key_Size = 2 + (Num_Variable_Key_Cols x 2) + Max_Var_Key_Size
Max_Var_Key_Sizeに追加されるバイトは、各可変長列を追跡するためのバイトです。 この数式では、すべての可変長列が 100% 満杯であることを前提としています。 可変長列ストレージ領域の割合が小さいと予想される場合は、その割合で Max_Var_Key_Size 値を調整して、テーブル全体のサイズをより正確に見積もることができます。
可変長列がない場合は、 Variable_Key_Size を 0 に設定します。
インデックス行のサイズを計算します。
Index_Row_Size = Fixed_Key_Size + Variable_Key_Size + Index_Null_Bitmap + 1 (インデックス行の行ヘッダー オーバーヘッドの場合) + 6 (子ページ ID ポインターの場合)
ページあたりのインデックス行数を計算します (1 ページあたり 8,096 バイトの空きバイト)。
Index_Rows_Per_Page = 8096 / (Index_Row_Size + 2)
インデックス行はページにまたがらないため、1ページあたりのインデックス行数は最も近い整数に切り捨てる必要があります。 数式の 2 は、ページのスロット配列内の行のエントリ用です。
インデックス内のレベルの数を計算します。
Non-leaf_Levels = 1 + 対数 Index_Rows_Per_Page (Num_Leaf_Pages / Index_Rows_Per_Page)
この値を最も近い整数に切り上げる。 この値には、クラスター化インデックスのリーフ レベルは含まれません。
インデックス内の非リーフ ページの数を計算します。
Num_Index_Pages = ∑Level (Num_Leaf_Pages / (Index_Rows_Per_PageLevel))
where 1 <= レベル<= 非葉レベル
各合計を最も近い整数に切り上げる。 簡単な例として、 Num_Leaf_Pages = 1000、 Index_Rows_Per_Page = 25 のインデックスを考えてみましょう。 リーフ レベルより上の最初のインデックス レベルには、1000 個のインデックス行が格納されます。これはリーフ ページごとに 1 つのインデックス行であり、1 ページあたり 25 行のインデックス行を格納できます。 つまり、これらの 1000 行のインデックスを格納するには、40 ページが必要です。 インデックスの次のレベルでは、40 行を格納する必要があります。 つまり、2 ページが必要です。 インデックスの最終レベルでは、2 行を格納する必要があります。 つまり、1 ページが必要です。 これにより、43 個の非リーフ インデックス ページが提供されます。 前の数式でこれらの数値を使用した場合、結果は次のようになります。
非葉ノードレベル = 1 + log25 (1000 / 25) = 3
Num_Index_Pages = 1000/(253)+ 1000/(25 2) + 1000/(251) = 1 + 2 + 40 = 43 (例で説明したページ数)。
インデックスのサイズを計算します (1 ページあたり合計バイト数 8192):
インデックス空間使用量 = 8192 x インデックスページ数
手順 3. 計算値の合計
前の 2 つの手順から取得した値の合計:
クラスター化インデックス サイズ (バイト) = Leaf_Space_Used + Index_Space_used
この計算では、次の点は考慮されません。
パーティショニング
パーティション分割による領域のオーバーヘッドは最小限ですが、計算は複雑です。 含めるのは重要ではありません。
割り当てページ
ヒープに割り当てられたページを追跡するために使用される IAM ページは少なくとも 1 つありますが、領域のオーバーヘッドは最小限であり、使用される IAM ページの正確な数を決定論的に計算するアルゴリズムはありません。
ラージ オブジェクト (LOB) 値
LOB データ型の
varchar(max)、varbinary(max)、nvarchar(max)、text、ntext、xml、imageの値の格納に使用される領域を正確に決定するアルゴリズムは複雑です。 必要な LOB 値の平均サイズを追加し、 Num_Rows乗算して、クラスター化インデックスの合計サイズに追加するだけで十分です。圧縮
圧縮インデックスのサイズを事前に計算することはできません。
スパース列
スパース列の領域要件については、「スパース列の 使用」を参照してください。
こちらもご覧ください
クラスター化インデックスと非クラスター化インデックスの概念
テーブルのサイズを見積もる
クラスター化インデックスの作成
非クラスター化インデックスを作成する
非クラスター化インデックスのサイズを見積もる
ヒープのサイズを見積もる
データベース サイズの見積もり