5

可能重复：
varchar(500) 是否比 varchar(8000) 有优势？

我目前正在处理一个有很多带有 varchar(50) 的列的表。我们现在必须在某些列中插入的数据超过 50 个字符，因此我们必须将这些列的列大小从 50 更改为 128，因为我们有很多列，更改单个列是浪费时间。

所以我向我的团队提出，为什么不把所有的列都改成varchar(128)。一些队友认为，这将在选择和加入操作期间导致性能下降。

现在我不是数据库专家，但我认为从 varchar 50 迁移到 varchar 128 不会对性能造成任何重大影响。

PS - 我们在这些列中没有任何名称、姓氏、地址类型的数据。

4

4 回答 4

5

varchar(50)并且varchar(128)从各个角度来看都会表现得几乎相同。对于 50 个字符以下的值，存储大小相同。它们可以互换地连接（varchar(50)连接varchar(128)），没有类型转换问题（即索引varchar(50)可以在连接中查找列varchar(128)），同样适用于 WHERE 谓词。在 SQL Server 2012 之前，增加varchar列的大小是一个非常快速的仅限元数据的操作，在 SQL Server 2012 之后，此操作在某些条件下可能是一个缓慢的 size-of-data-update-each-record 操作，类似于那些描述的在添加一个可为空的列可以更新整个表。

任何列长度更改都可能引起一些问题：

  • 处理意外大小值的应用程序问题。如果编码不当，本机可能会遇到缓冲区大小问题（即较大的大小会导致缓冲区溢出）。托管应用程序不太可能出现严重问题，但可能会出现一些小问题，例如值不适合屏幕或报告的列宽。
  • 插入或更新时截断值导致的 T-SQL 错误
  • 发生 T-SQL 静默截断并导致不正确的值（例如，@variablesvarchar(50)在存储过程中声明）
  • 可能会达到最大行大小或最大索引大小等限制。例如。你今天有一个 8 列类型的复合索引varchar(50)，扩展到varchar(128)将超过 900 的最大索引大小并触发警告。

Martin 关于内存授权增加的警告是一个非常有道理的担忧。如果这确实是一个问题，我会购买更多的 RAM。

于 2012-07-16T09:23:29.087 回答
2

请在此处查看 varchar(max) 与 varchar(n) 的性能比较

于 2012-07-16T08:47:56.577 回答
0

我建议只更改需要更改的列。如果您在任何列中不需要超过 50 个字符，请不要更改它。

为什么你有兴趣使所有列的长度都相同？我怀疑所有列都有相同的长度要求。

于 2012-07-16T09:44:10.707 回答
0

这样的列有多少？最佳实践规则说您需要仔细计划每一列并相应地定义大小。您应该确定适合 varchar(128) 的列，而不是盲目地增加所有列的大小。

于 2012-07-16T08:08:16.437 回答