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

Question

可能重复：
varchar(500)和varchar(8000)相比有什么优势？ 我目前正在处理一个有许多长度为50的varchar列的表格。现在我们需要插入一些超过50字符的数据，因此我们必须将这些列从50更改为128，由于我们有很多列，逐个更改会浪费时间。

所以我向我的团队建议，为何不将所有列都更改为varchar（128）呢？其中一些团队成员认为这将在选择和连接操作期间导致性能下降。

现在我不是数据库专家，但我不认为从varchar 50变为varchar 128会导致任何显着的性能损失。

P.S-那些列中没有任何名字、姓氏、地址等数据。

- Sumedh

---

好的，它只会在查询中涉及到varchar列的连接操作时影响性能。你有使用varchar列进行连接的查询吗？很多人会说这是不可取的... - AakashM

Answer 1

varchar(50)和varchar(128)在任何方面都基本相同。对于长度小于50个字符的值，存储大小相同。它们可以互换使用（例如：varchar(50)与varchar(128)），不会出现类型转换问题（即：在连接中，varchar(50)上的索引可以搜索与之连接的列varchar(128)），同样适用于WHERE谓词。在SQL Server 2012之前，增加varchar列的大小是一个非常快的元数据操作，但在某些情况下，这个操作可能会变成一个缓慢的数据更新操作，类似于添加可空列可能会更新整个表中描述的那些情况。

任何列长度更改都可能出现一些问题：

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

Martin关于内存授权增加的警告是非常重要的问题。如果确实存在这个问题，我建议增加更多的RAM。

- Remus Rusanu

---

Remus，这些都是很好的观点，显然我们会进行头脑风暴。我想知道性能问题是否真实存在，而你和马丁给了我答案，非常感谢。 - Sumedh

Answer 2

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

- sganesh

---

问题不在于 varchar(max) 和 varchar(n) 的区别，而在于 varchar(n1) 和 varchar(n2) 的比较。 - Martin Smith

我同意，但如果您创建任何不需要更多空间的列，则会出现相同的情况。最好只创建所需的空间，创建更多的空间将导致在连接表和where子句时性能问题。 - sganesh

Answer 3

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

- Geek

---

大约有120个列，最初它们全部都是varchar(50)（我仍然没有得到令人满意的答案为什么所有列都是varchar 50）。是的，我同意，最佳实践是识别列，负责此事的人正在忙于其他高优先级问题，但当产品因为大小限制在客户面前抛出错误时，这是令人尴尬的。 - Sumedh

我会说它们都是varchar(50)，因为当你输入“varc”时，SQL会自动补全为“varchar(50)”。 - strattonn

Answer 4

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

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

- Gulli Meel