Un ejemplo en el que esto puede marcar la diferencia es que puede evitar una optimización del rendimiento que evita agregar información de versiones de filas a las tablas con desencadenadores posteriores.
Esto está cubierto por SQL Kiwi aquí
El tamaño real de los datos almacenados es irrelevante: lo que importa es el tamaño potencial.
De manera similar, si se usan tablas optimizadas para memoria desde 2016, ha sido posible usar columnas LOB o combinaciones de anchos de columna que potencialmente podrían exceder el límite de entrada pero con una penalización.
Las columnas (máx.) Siempre se almacenan fuera de la fila. Para otras columnas, si el tamaño de la fila de datos en la definición de la tabla puede exceder los 8.060 bytes, SQL Server empuja las columnas de longitud variable más grandes fuera de la fila. Nuevamente, no depende de la cantidad de datos que almacene allí.
Esto puede tener un gran efecto negativo en el consumo y el rendimiento de la memoria
Otro caso en el que la declaración excesiva de los anchos de columna puede suponer una gran diferencia es si la tabla se procesará alguna vez mediante SSIS. La memoria asignada para columnas de longitud variable (no BLOB) es fija para cada fila en un árbol de ejecución y es según la longitud máxima declarada de las columnas, lo que puede conducir a un uso ineficiente de búferes de memoria (ejemplo) . Si bien el desarrollador del paquete SSIS puede declarar un tamaño de columna más pequeño que la fuente, este análisis se realiza mejor desde el principio y se aplica allí.
De vuelta en el motor de SQL Server, un caso similar es que al calcular la concesión de memoria para asignar a las SORToperaciones, SQL Server asume quevarchar(x) columnas consumirán en promediox/2 bytes .
Si la mayoría de sus varcharcolumnas están más llenas, esto puede llevar a que las sortoperaciones se desbordentempdb .
En su caso, si sus varcharcolumnas se declaran como8000 bytes pero en realidad tienen un contenido mucho menor que ese, a su consulta se le asignará memoria que no requiere, lo que obviamente es ineficiente y puede conducir a esperas por concesiones de memoria.
Esto se trata en la Parte 2 del Webcast 1 de talleres de SQL que se puede descargar desde aquí o ver más abajo.
use tempdb;
CREATE TABLE T(
id INT IDENTITY(1,1) PRIMARY KEY,
number int,
name8000 VARCHAR(8000),
name500 VARCHAR(500))
INSERT INTO T
(number,name8000,name500)
SELECT number, name, name /*<--Same contents in both cols*/
FROM master..spt_values
SELECT id,name500
FROM T
ORDER BY number
SELECT id,name8000
FROM T
ORDER BY number
