使用的列大小比必要的大得多

我正在与其他人创建SQL Server数据库。其中一张表很小（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 Server使用列长度。所以，是的，总之，您应该始终为数据调整大小。

内存分配基于查询返回的行数乘以列声明长度的一半。

话虽如此，在这种情况下，如果您有6行，​​您可能不想过早优化。除非您将此表联接到具有数百万行的另一个表，否则varchar（24）和varchar（32）甚至是varchar（128）之间不会有巨大的差异。

您的第二个问题询问如何按二进制倍数对齐列长度。根本不需要这样做，因为SQL Server将所有数据存储在8KB页中，而不管每列的长度如何。

有6行，没有，将没有明显的收益。整个表格可容纳在单个页面上，因此降低了您将在该页面上使用的最大潜在空间，而实际上仍然占据了整个页面，从实际意义上讲并没有什么不同。

但是，在较大的表上，正确调整大小至关重要。原因是内存估计将基于每个值将填充50％的假设。因此，如果您具有varchar（128），则无论实际数据如何，每个值都将占用64个字节，因此内存授权将为64b *行数。如果所有值都等于或小于32个字符，则将其设为varchar（64）甚至varchar（32）可能是一个更好的选择。如果很大一部分价值接近或接近上限，您甚至可以主张char消除波动性。

至于将字符串长度限制为2的幂的好处，我认为在当今的硬件上，没有人能证明任何明显的好处。