SQL Server varchar（50）和varchar（128）性能差异

可能重复：

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

所以我向我的团队建议，为什么不把所有列都改成varchar（128）。一些队友认为，这将在选择和加入操作期间造成性能下降

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

---

另外，我们在这些栏中没有任何姓名、姓氏、地址等数据。

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

请检查此处

varchar（50）

和

varchar（128）

从各个角度来看，它们的行为几乎相同。50个字符以下的值的存储大小相同。它们可以互换地联接（

varchar（50）

与

varchar（128）

联接）而不存在类型转换问题（即

varchar（50）

上的索引可以在联接中查找列

varchar（128）

），这同样适用于WHERE谓词。在SQL Server 2012之前，增加

varchar

列的大小是一个非常快速的仅元数据操作，而在SQL Server 2012之后，此操作在某些条件下可能是缓慢的数据更新操作，类似于中描述的操作

任何列长度更改都可能导致一些问题：

• 处理意外大小值时出现的应用程序问题。如果编码不当，本机可能会遇到缓冲区大小问题（即，较大的大小可能导致缓冲区溢出）。托管应用程序不太可能出现严重问题，但可能会出现一些小问题，如屏幕上的列宽或报告上的值不合适
• 插入或更新时截断值导致的T-SQL错误
• T-SQL静默截断发生并导致不正确的值（例如，在存储过程中@variables声明为

  varchar（50）

  ）
• 可能达到最大行大小或最大索引大小等限制。例如，您现在在8列上有一个复合索引，类型为

  varchar（50）

  ，扩展到

  varchar（128）

  将超过最大索引大小900并触发警告

---

马丁关于记忆授予量增加的警告是一个非常合理的担忧。如果这确实是一个问题，我会购买更多的RAM。

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

---

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

好吧，如果您有对

varchar

列进行连接的查询，那么这只会影响连接操作期间的性能。您是否有在

varchar

列上联接的查询？很多人会说这是不可取的……问题不是关于

varchar（max）

vs

varchar（n）

而是关于

varchar（n1）

vs

varchar（n2）

我同意，但如果您创建的任何列确实不需要更多空间，情况也是一样的。最好只创建所需的空间，创建更多空间将导致连接表和where子句时的性能问题。大约有120列，最初所有列都是varchar（50）（我仍然没有令人满意的答案，为什么所有的栏目都是varchar 50）。是的，我同意，最好的做法是确定栏目，负责这项工作的人正忙于处理其他一些高优先级的问题，但当产品在客户面前因尺寸限制而抛出错误时，这会让人尴尬。我认为它们都是varchar（50）因为当您输入“varc”时，SQL auto将以“varchar（50）”Remus完成，这些都是很好的观点，显然我们将就此进行头脑风暴。我想知道性能问题是否真实，我得到了我的答案，多亏了您和Martin。