Ancho de columna de SQL Server VARCHAR

Al buscar en la web, he encontrado consejos contradictorios sobre si hay un impacto en el rendimiento al especificar columnas VARCHAR demasiado anchas, por ejemplo, VARCHAR (255) cuando VARCHAR (30) probablemente lo hará.

Constantemente veo acuerdo en que hay un impacto en el rendimiento si toda la fila supera los 8060 bytes. Aparte de eso, veo desacuerdo.

¿Es cierto el reclamo The default is SET ANSI PADDING ON = potential for lots of trailing spaces? Siempre que el ancho total de la fila sea inferior a 8060, ¿existen problemas de rendimiento real en el sobredimensionamiento de las columnas VARCHAR?

Evidencia de que el ancho de columna importa

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

¿Cuáles son las consecuencias de configurar varchar (8000)?

Evidencia de que el ancho de columna NO importa

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

La pregunta podría formularse mejor como:

"¿Cuál es la ventaja de especificar en exceso la longitud máxima de una columna de longitud variable?"

En general, hay pocas ventajas y varias desventajas, como señalan las diversas respuestas vinculadas. Además de cualquier otra inquietud, considere que SQL Server no es de código abierto: hay muchos 'números mágicos' y heurísticas aplicadas en función de la información proporcionada al sistema. Sin acceso al código fuente, nunca podríamos estar completamente seguros de cuál podría ser el impacto de esta práctica.

En algunos casos , donde la longitud promedio de una columna es significativamente mayor que el 50% asumido por SQL Server al calcular las asignaciones de memoria de clasificación / hash, puede ver una mejora en el rendimiento al especificar en exceso la longitud máxima. Esta es una solución dudosa , y probablemente solo debería aplicarse de forma explícita CASTo CONVERT(¡con comentarios!) En lugar de cambiar la definición de la columna base. A veces, será preferible volver a escribir la consulta para ordenar las claves en lugar de las filas completas de todos modos.

Cuando el tamaño máximo de la fila puede exceder el límite de la fila (incluso si no hay filas), eliminar filas puede causar una división inesperada de la página si hay un activador. Las actualizaciones también pueden conducir a la fragmentación a través del mismo mecanismo.

SQL Server hace un trabajo bastante bueno en la mayoría de los casos en que se proporciona información buena y precisa de metadatos. Comprometer este principio por 'conveniencia' me parece imprudente. Un enfoque sensato es elegir un valor de longitud máxima que sea razonable de acuerdo con los datos reales que se almacenarán y los cambios previsibles.

Como indicó, siempre y cuando el tamaño de la fila no exceda 8060 (o sea el valor máximo establecido), no hay diferencia de rendimiento al usar VARCHAR (30) o VARCHAR (255) o mayor. La comparación de CHAR a VARCHAR del artículo vinculado no es realmente pertinente. Aunque estoy de acuerdo en que no debe especificar más espacio del que está seguro que necesita, en muchos casos no sabe cuánto espacio necesitará realmente. Por lo tanto, sea liberal con el espacio VARCHAR: estoy bastante seguro de que aumentar el tamaño de los campos requiere una reconstrucción de la tabla, mientras que disminuir es una simple declaración ALTER TABLE.