web-dev-qa-db-ja.com

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

誰かと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列のchar長を調べています。その値はおそらく32文字を超えたり、24文字を超えたりすることはないと思います。たとえば、この列をvarchar(32)？に変更します。

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

sql-serverdatabase-designvarchar
16
elbillaf

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

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

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

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

15
Max Vernon

6行の場合、いいえ、目に見えるメリットはありません。そのテーブル全体が1つのページに収まるので、そのページ全体を占有しながら、そのページで使用する可能性のある最大の潜在的なスペースを小さくすることは、実際にはまったく同じです。

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

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

14
Aaron Bertrand