Eri*_* J. 15 sql-server-2008 sql-server varchar
在网上搜索，我发现在指定过宽的 VARCHAR 列时是否会影响性能的建议相互矛盾，例如 VARCHAR(255) 时 VARCHAR(30) 可能会这样做。
我一致认为，如果整行超过 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 bytesCan 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列宽无关紧要的证据
If you're talking about varchar and nvarchar then no, there is no penalty for allowing a higher field length.
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 在大多数情况下都做得很好，因为它提供了来自元数据的良好、准确的信息。为了“方便”而妥协这一原则在我看来是不明智的。明智的做法是根据要存储的实际数据以及任何可预见的变化，选择合理的最大长度值。