SQL Server varchar(50) 和 varchar(128) 性能差异 [重复]答案

【问题标题】：SQL Server varchar(50) and varchar(128) performance difference [duplicate]SQL Server varchar(50) 和 varchar(128) 性能差异 [重复]
【发布时间】：2012-07-15 00:46:03
【问题描述】：

可能重复：
is there an advantage to varchar(500) over varchar(8000)?

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

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

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

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

【问题讨论】：

好吧，如果您有在 varchar 列上连接的查询，它只会影响连接操作期间的性能。是否您有加入varchar 列的查询？很多人会说这是不可取的......

标签： sql sql-server

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

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-记录特定条件下的操作，类似于Adding a nullable column can update the entire table中描述的操作。

任何列长度变化都会引起一些问题：

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

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

【讨论】：

Remus，这些都很好，显然我们会对此进行头脑风暴。我想知道性能问题是否真实，感谢您和 Martin，我得到了答案。

【解决方案3】：

请在此处查看 Performance Comparison-of-varchar(max) vs varchar(n)

【讨论】：

问题不在于varchar(max) vs varchar(n)，而在于varchar(n1) vs varchar(n2)
我同意，但是如果您创建任何确实不想要更多空间的列更好地仅创建所需的空间，并且创建更多空间将导致连接表和 where 子句时的性能问题，情况也是如此。

【解决方案4】：

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

【讨论】：

大约有 120 列，最初都是 varchar(50)（我仍然没有满意的答案，为什么所有列都是 varchar 50）。是的，我同意，最好的做法是识别列，负责这方面的人忙于处理其他一些高优先级问题，但是当产品由于尺寸限制而在客户面前抛出错误时，这很尴尬。
我会说它们都是 varchar(50)，因为当您键入尽可能多的“varc”时，SQL 会使用“varchar(50)”自动完成