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

Question

Me pregunto si hay 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 columna nvarchar (max), o cualquier cosa que abona por tener que agregar la restricción en el límite de tamaño?

Gracias!

Answer 1

Estrictamente hablando, los tipos MAX siempre serán un poco más lentos que los tipos que no son MAX, ver Performance comparison of 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: utilice un tipo MAX, el dolor de convertir esta columna más tarde en un tipo MAX no vale la pena el beneficio de rendimiento menor de MAX tipos.

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

BTW, 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 es en Table and Index Organization:

unidad de asignación ROW_OVERFLOW_DATA

para cada partición utilizada por una mesa (montón o mesa agrupado), índice o vista indizada, no es una asignación ROW_OVERFLOW_DATA unidad. Esta unidad de asignación contiene cero (0) páginas hasta una fila de datos con columnas de longitud variable (varchar, nvarchar, varbinary o sql_variant) en la unidad de asignación IN_ROW_DATA excede el límite de tamaño de fila 8 KB.Cuando se alcanza la limitación de tamaño , SQL Server mueve la columna con el ancho más grande de esa fila a una página en la unidad de asignación ROW_OVERFLOW_DATA . Se mantiene en la página original un puntero de 24 bytes a este dato fuera de la fila .

Así que no son las columnas de más de 4KB, son las filas que no caben en el espacio libre en la página, y no es el 'restante', es toda la columna.

Answer 2

no se puede crear un índice en una columna de más de 900 bytes. Las columnas que son del objeto grande (LOB) tipos de datos ntext, texto, varchar(max), nvarchar (max), varbinary (max), XML, o la imagen no se pueda especificar como columnas de clave para un índice

sin embargo se puede utilizar 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

Elegir nvarchar (max) también puede afectar a las optimizaciones del plan de ejecución que se adaptan automáticamente por el motor de servidor sql.