必要以上に大きい列サイズを使用する

他の人とSQL Serverデータベースを作成しています。テーブルの1つは小さく（6行）、データはおそらく一定のままです。新しい行が追加される可能性はほとんどありません。テーブルは次のようになります。

CREATE TABLE someTable (
    id int primary key identity(1,1) not null,
    name varchar(128) not null unique
    );
INSERT INTO someTable values ('alice', 'bob something', 'charles can dance', 'dugan was here');

私はそのname列の文字の長さを調べていますが、その値はおそらく32文字を超えることは決してなく、おそらく24文字を超えることはないと思います。この列を変更する利点はありますか、たとえば、varchar(32)？

また、デフォルトの列サイズを4、8、32などの倍数に維持することには利点がありますか？

SQL Serverは、クエリ処理にメモリを割り当てるときに列の長さを使用します。したがって、はい、要するに、データに合わせて常に列のサイズを調整する必要があります。

メモリ割り当ては、クエリによって返された行の数に、宣言された列の長さの半分を掛けた値に基づいています。

とはいえ、この場合、6行ある場合は、おそらく時期尚早に過剰に最適化したくないでしょう。このテーブルを数百万行の別のテーブルに結合しない限り、varchar（24）とvarchar（32）、またはvarchar（128）との間に大きな違いはありません。

2番目の質問では、2の倍数で列の長さを揃える方法について質問します。SQL Serverは、各列の長さに関係なく、すべてのデータを8KBページに保存するため、これはまったく必要ありません。

6行の場合、いいえ、目に見える利点はありません。そのテーブル全体が1ページに収まるので、そのページで使用する潜在的な最大スペースを減らしながら、そのページ全体を占有することは、実際的にはまったく違いはありません。

ただし、大きなテーブルでは、適切なサイズ設定が重要です。その理由は、メモリの見積もりは、すべての値が50％になるという仮定に基づいているためです。したがって、varchar（128）がある場合、実際のデータに関係なく、すべての値は64バイトを占有することが予想されるため、メモリ許可は64b *行数になります。すべての値が32文字以下になる場合は、おそらくvarchar（64）またはvarchar（32）にすることをお勧めします。値の大部分が上限に近い場合、または上限に達した場合、charがボラティリティをそこから取り除くと主張することさえできます。

文字列の長さを2の累乗に制限することの利点については、今日のハードウェアでは誰も明らかな利点を実証できるとは思いません。