sql server - many - Rendimiento SQL: ¿Hay algún golpe de rendimiento usando NVarchar(MAX) en lugar de NVarChar(200)

text length sql

Question

Me pregunto si existe alguna desventaja al definir una columna de tipo nvarchar (max) en lugar de darle un tamaño máximo (más pequeño).

Leí en alguna parte que si el valor de la columna tiene más de 4 KB, los datos restantes se agregarán a un área de "desbordamiento", lo cual está bien.

Estoy creando una tabla en la que la mayoría de las veces el texto será de algunas líneas, pero me preguntaba si hay alguna ventaja al establecer un límite inferior y luego agregar una validación para evitar romper ese límite.

¿Existe alguna restricción en la creación de índices con la columna nvarchar (max), o cualquier cosa que pague por tener que agregar la restricción en el límite de tamaño?

¡Gracias!

Answer 1

Elegir nvarchar (max) también puede afectar las optimizaciones del plan de ejecución que el motor de servidor SQL adapta automáticamente.

Answer 2

no se puede crear un índice en una columna de más de 900 bytes. Las columnas que son de los tipos de datos de objeto grande (LOB) ntext, text, varchar(max) , nvarchar (max), varbinary (max), xml o image no se pueden especificar como columnas clave para un índice

Sin embargo, puedes usar included columns

Se permiten todos los tipos de datos, excepto texto, ntext e imagen. El índice debe crearse o reconstruirse fuera de línea (ONLINE = OFF) si alguna de las columnas no clave especificadas son varchar (max), nvarchar (max) o varbinary (max) tipos de datos.

Answer 3

Estrictamente hablando, los tipos MAX siempre serán un poco más lentos que los tipos que no son MAX, ver Comparación de rendimiento de varchar (max) vs. varchar (N) . Pero esta diferencia nunca es visible en la práctica, donde simplemente se convierte en ruido en el rendimiento general impulsado por IO.

Su principal preocupación no debe ser el rendimiento de MAX frente a no MAX. Debería preocuparse por la pregunta: ¿será posible que esta columna tenga que almacenar más de 8000 bytes? Si la respuesta es sí, incluso si es un sí muy improbable, entonces la respuesta es obvia: use un tipo MAX, el dolor de convertir esta columna más tarde a un tipo MAX no vale la ventaja de rendimiento menor de los tipos que no son MAX. .

Otras preocupaciones (posibilidad de indexar esa columna, indisponibilidad de las operaciones de índice en línea para las tablas con columnas MAX) ya fueron abordadas por la respuesta de Denis.

Por cierto, la información sobre las columnas de más de 4 KB que tienen datos restantes en un área de desbordamiento es incorrecta. La información correcta está en la Organización de tabla e índice :

ROW_OVERFLOW_DATA Unidad de asignación

Para cada partición utilizada por una tabla (montón o tabla agrupada), índice o vista indizada, hay una unidad de asignación ROW_OVERFLOW_DATA. Esta unidad de asignación contiene cero (0) páginas hasta que una fila de datos con columnas de longitud variable (varchar, nvarchar, varbinary o sql_variant) en la unidad de asignación IN_ROW_DATA exceda el límite de 8 KB de tamaño de fila. Cuando se alcanza la limitación de tamaño, SQL Server mueve la columna con el ancho más grande desde esa fila a una página en la unidad de asignación ROW_OVERFLOW_DATA. Un puntero de 24 bytes a esta información fuera de la fila se mantiene en la página original.

Entonces, ¿no son las columnas de más de 4 KB, las filas que no caben en el espacio libre de la página y que no son ''restantes'', es la columna completa.