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

22

Dado que varchar ocupa un espacio en disco proporcional al tamaño del campo, ¿hay alguna razón por la que no siempre deberíamos definir varchar como el máximo, por ejemplo, varchar(8000)en SQL Server?

En crear tabla, si veo a alguien haciendo varchar(100), debería decirle que no, ¿estás equivocado varchar(8000)?

sql-server varchar Aleksandr Levchuk
fuente
Creo que tenemos que diferenciar aquí entre el uso en crear tabla y el uso en declaraciones de parámetros de procedimientos almacenados. Para la segunda interpretación, vea mi pregunta dba.stackexchange.com/questions/1772/…
bernd_k

Respuestas:

18
  • La longitud es una restricción en los datos (como CHECK, FK, NULL, etc.)
  • Rendimiento cuando la fila supera los 8060 bytes
  • No puede tener una restricción o índice únicos (el ancho de la columna clave debe ser <900)
  • El valor predeterminado es SET ANSI PADDING ON = potencial para almacenar muchos espacios finales
  • SQL Server asumirá que la longitud promedio es de 4000 para las operaciones de clasificación, asignando memoria en función de esto (necesita encontrar un enlace para respaldar esto, pero me oxida mientras lo hago :-)

Resumen: no lo hagas.

gbn
fuente
Rendimiento cuando la fila supera los 8060 bytes . ¿Eso se refiere a los bytes reales utilizados y no a los bytes máximos permitidos?
bernd_k
@bernd_k: 8060 = la mayor cantidad de datos para una fila que cabe en una sola página 8192. Incluir fila por encima. Resto (132 bytes) = sobrecarga de página
gbn
Eso significa que el rendimiento disminuye cuando realmente se usa el tamaño más grande, no por el simple hecho de que está permitido su uso.
bernd_k
@bernd_k: cualquier disminución del rendimiento es causada por 1. asignación de memoria para clases, etc. 2. Desbordamiento de fila (> 8060 bytes). El hecho de tener 10 caracteres en cada varchar (8000) es irrelevante hasta que se cumplan estas condiciones (SQL advertirá sobre posibles errores más adelante para las claves de índice)
gbn
¿Ordenar una tabla con una columna varchar (100) llena de campos de 100 bytes de longitud vale otra pregunta, porque la clasificación supone un promedio de 50 caracteres?
bernd_k
7

Suponiendo que se refiere a SQL Server, se me ocurre uno.

Hay un límite para el tamaño (8K) de una fila en una tabla y SQL le permite definir campos varchar que teóricamente podrían exceder ese límite. Por lo tanto, el usuario podría obtener errores si pone demasiados datos en el campo relacionado con eso.

A partir de SQL 2K8, puede superar este límite, pero existen implicaciones de rendimiento .

Además, existe toda la verificación de razonabilidad de limitar el tamaño a lo que espera que se vean los datos. Si desea un campo de longitud ilimitado, ¿por qué no ir con texto o ntext?

JohnFx
fuente
Entonces, ¿los tipos de datos de texto y ntext se almacenan de una manera que no afecta el rendimiento?
Chad
Esos tipos no contribuyen tanto al límite de tamaño de fila de 8K en una tabla porque los datos reales se almacenan en una tabla separada debajo de las cubiertas en lugar de estar en línea con el resto de las columnas. Todavía hay un impacto en el rendimiento, pero por diferentes razones. También hay limitaciones en el soporte de funciones en estos campos en comparación con varchar y nvarchar
JohnFx
text y ntext están en desuso a favor de varchar (max).
Phil Helmer
3

¿Seguramente depende de qué información se almacena en el campo?

Algunas cosas tendrán una longitud máxima por varias razones y si tiene que haber una longitud máxima, entonces esa debería ser la longitud de su campo.

Si teóricamente no hay una longitud máxima, entonces me preguntaría por qué se usaría varchar.

Toby
fuente
3

Contexto de las bases de datos de Oracle Aprendí que usar siempre el tamaño de campo más pequeño para las columnas de la base de datos tiene un inconveniente.

Cuando se mueven datos mediante importación, exportación desde una base de datos con clasificación de un solo byte a una con clasificación de múltiples bytes (como Oracle XE), la longitud en bytes puede aumentar y la importación de los datos en las tablas creadas por importación falla. Por supuesto, Oracle tiene la opción de definir la longitud de varchar2 como char o byte.

Mi punto aquí es que no siempre es prudente definir un campo siempre tan pequeño como sea posible. He visto muchas tablas alternativas para aumentar los campos con posterioridad (debido a los requisitos modificados).

Tener un 20% - 100% de campo sin usar con es una opción discutible aquí.

bernd_k
fuente