490 M行と55 GBの表スペースがある表があるため、1行あたり約167バイトです。テーブルには3つの列があります：a VARCHAR(100)、a DATETIME2(0)、およびa SMALLINT。VARCHARフィールド内のテキストの平均の長さは約21.5なので、生データは行ごとに約32バイトである必要があります。22+ 2はVARCHAR、6はDATETIME2、および2は16ビット整数です。
上記のスペースはデータのみであり、インデックスではないことに注意してください。[プロパティ]で報告される値を使用しています| ストレージ| 全般| データスペース。
もちろん、ある程度のオーバーヘッドが必要ですが、特に大きなテーブルの場合、1行あたり135バイトはかなり多いようです。これはなぜでしょうか？他の誰かが同様の乗数を見ましたか？必要な追加スペースの量に影響する要因は何ですか？
比較のために、2つのINTフィールドと1 M行のテーブルを作成してみました。必要なデータ領域は16.4 MBでした。8バイトの生データと比較して、行あたり17バイトです。INTとVARCHAR(100)実際のテーブルと同じテキストが入力された別のテストテーブルは、行ごとに39バイト（44 K行）を使用します。
したがって、実動テーブルにはかなり多くのオーバーヘッドがあります。これは大きいからですか？インデックスサイズはだいたいN * log（N）になると思いますが、実際のデータに必要なスペースが非線形である理由はわかりません。
ポインタを事前に感謝します！
編集：
リストされているすべてのフィールドはNOT NULLです。実際のテーブルには、VARCHARフィールドとDATETIME2フィールドの順にクラスターPKがあります。2つのテストの場合、最初のテストINTは（クラスター化された）PKでした。
重要な場合：テーブルはpingの結果の記録です。フィールドは、URL、ping日付/時刻、およびミリ秒単位の待機時間です。データは常に追加され、更新されることはありませんが、データは定期的に削除され、URLごとに1時間あたり数個のレコードに削減されます。
編集：
非常に興味深い答えがここにいることを示唆している、多くの読み取りと書き込みとインデックスのために、再構築は有益ではないかもしれません。私の場合、消費されるスペースは懸念事項ですが、書き込みパフォーマンスがより重要な場合は、ゆるいインデックスを使用した方が良いかもしれません。