SQL Server VARCHAR列宽

在网上搜索时，我发现在指定超宽VARCHAR列（例如VARCHAR（30）可能会这样做时，例如VARCHAR（255））时是否会对性能产生影响的建议相互冲突。

我始终认为，如果整行超过8060字节，则会对性能造成影响。除此之外，我看到了分歧。

要求是真的The default is SET ANSI PADDING ON = potential for lots of trailing spaces吗？只要总行宽小于8060，在VARCHAR列过大设置时是否存在真正的性能问题？

列宽很重要的证据

The same goes for CHAR and VARCHAR data types. Don’t specify more characters in character columns that you need.

http://www.sql-server-performance.com/2007/datatypes/

• Length is a constraint on the data (like CHECK, FK, NULL etc)
• Performance when the row exceeds 8060 bytes
• Can not have unique constraint or index (key column width must be < 900)
• The default is SET ANSI PADDING ON = potential for lots of trailing spaces

设置varchar（8000）有什么后果？

列宽无关紧要的证据

If you're talking about varchar and nvarchar then no, there is no penalty for allowing a higher field length.

/programming/7025996/overstating-field-size-in-database-design

The varchar datatype, by contrast, consumes only the amount of actual space used plus 2 bytes for overhead

http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf

这个问题可能更好地表述为：

“过度指定可变长度列的最大长度有什么好处？”

通常，几乎没有什么优点，而各种链接的答案指出了几个缺点。除了其他问题外，请考虑SQL Server不是开源的：基于提供给系统的信息，有很多“魔术数字”和启发式方法。如果没有源代码访问权限，我们将永远无法完全确定这种做法的影响。

在某些情况下，当列的平均长度显着高于SQL Server在计算排序/哈希内存授予量时假定的50％时，通过过度指定最大长度可能会提高性能。这是一个可疑的解决方法，可能仅应通过显式CAST或CONVERT（带有注释！）应用，而不是更改基本列定义。有时，最好重写查询以对键进行排序，而不是对整个行进行排序。

如果最大行大小可能超过行内限制（即使实际上没有行），则删除行会导致意外的页面拆分（如果存在触发器）。更新也可能通过相同的机制导致碎片化。

在大多数情况下，SQL Server可以从元数据中获得良好，准确的信息，因此效果很好。在我看来，为了“便利”而牺牲这一原则似乎是不明智的。明智的方法是根据要存储的实际数据以及任何可预见的变化来选择一个合理的最大长度值。

如您所指出的，只要行大小不超过8060（或将最大值设置为），使用VARCHAR（30）或VARCHAR（255）或更大的值就不会有性能差异。链接文章中的CHAR与VARCHAR比较并没有实际意义。尽管我同意您不应指定超出您确定所需空间的空间，但是在许多情况下，您并不知道实际需要多少空间。因此，请放心使用VARCHAR空间-我很确定增加字段的大小需要重新构建表，而减小是简单的ALTER TABLE语句。