SQL Server varchar(50) 和 varchar(128) 性能差异

Question

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

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

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

现在我不是数据库专家，但我不认为从 varchar 50 迁移到 varchar 128 会导致任何显着的性能下降。

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

Answer 1

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 关于内存授权增加的警告是一个非常有效的问题。如果这确实会成为一个问题，我会购买更多的内存。