SQL varchar列长度的最佳做法

Question

已关闭 。这个问题是基于观点的。它当前不接受答案。

想改善这个问题吗？ 更新问题，以便通过编辑此帖子以事实和引用的形式回答。

2个月前关闭。

每次设置新的SQL表或varchar向现有表添加新列时，我都想知道一件事：的最佳价值是什么length。

假设您有一个名为nametype 的列varchar。因此，您必须选择长度。我想不出一个名称>
20个字符，但您永远不会知道。但是我总是使用四舍五入到下一个2 ^
n数字，而不是使用20。在这种情况下，我将选择32作为长度。我这样做是因为从计算机科学家的角度来看，数字2 ^ n
even在我看来比其他数字要多，我只是假设下面的体系结构可以更好地处理这些数字。

另一方面，例如，当您选择创建varchar列时，MSSQL服务器会将默认长度值设置为50。那让我开始思考。为什么是50？它只是一个随机数，还是基于平均列长，还是什么？

不同的SQL Server实现（例如MySQL，MSSQL，Postgres等）也可能具有（也可能是）不同的最佳列长值。

Answer 1

据我所知，没有DBMS有任何“优化”可以使长度VARCHAR为a的2^n性能比max长度不是2的幂的性能更好。

我认为早期的SQL Server版本实际上将VARCHAR255的长度与最大长度较高的长度区别对待。我不知道是否仍然如此。

对于几乎所有的DBMS，所需的实际存储空间仅取决于您放入其中的字符数，而不取决于max您定义的长度。因此，从存储的角度（也可能是性能的角度），无论您将列声明为VARCHAR(100)还是都没有任何区别VARCHAR(500)。

您应该max将为VARCHAR列提供的长度看作是一种约束（或业务规则），而不是技术/实际的事物。

对于PostgreSQL来说，最好的设置是使用text不受长度限制CHECK CONSTRAINT的字符集，它将字符数限制为您的业务需求。

如果该要求发生变化，那么更改检查约束比更改表要快得多（因为不需要重写表）

可以对Oracle和其他对象应用相同的方法-在Oracle中，它VARCHAR(4000)不是，text而是。

我不知道SQL Server VARCHAR(max)和VARCHAR(500)SQL Server
之间是否存在物理存储差异。但是varchar(max)与相比，使用显然会对性能产生影响varchar(8000)。

看到此链接（由Erwin Brandstetter发表评论）

编辑2013-09-22

关于bigown的评论：

在9.2之前的Postgres版本中（我写初始答案时不可用），对列定义的更改 确实
重写了整个表，请参见例如此处。从9.2开始，情况不再如此，快速测试确认增加具有120万行的表的列大小实际上仅需0.5秒。

对于Oracle来说，从更改大表的varchar列所需的时间来看，这似乎也是正确的。但是我找不到任何参考。

对于MySQL，该手册会说 “ 在大多数情况下，ALTER TABLE为原始表创建一个临时副本
”。我自己的测试证实了：ALTER TABLE在具有120万行的表上运行（与我对Postgres的测试相同）以增加列的大小需要1.5分钟。但是，在MySQL中，您 不能
使用“替代方法”来使用检查约束来限制列中的字符数。

对于SQL Server，我找不到明确的声明，但是执行增加varchar列大小的执行时间（同样是上表的120万行表）表明 没有 重写。

编辑2017-01-24

似乎我（至少部分地）对SQL Server错误。请参阅Aaron
Bertrand的答案，该答案表明a
nvarchar或varcharcolumn 的声明长度对性能有很大的影响。