Hola usuario de nuestra página, encontramos la solución a lo que buscabas, continúa leyendo y la obtendrás más abajo.
Solución:
Tamaño todos y cada uno columna apropiadamente. NO use un tamaño “estándar” para cada columna. Si solo necesita 30 caracteres, ¿por qué crear una columna que pueda manejar 255? Me alegra que no esté defendiendo el uso varchar(max) para sus columnas de cadena.
Este es un consejo especialmente prudente si alguna vez necesita indexar una columna, o si está utilizando una columna como clave principal y tiene referencias de clave externa. SQL Server usa el tamaño de cada columna en su optimizador de consultas para comprender los requisitos de memoria estimados para el procesamiento de consultas. Tener columnas de gran tamaño puede ser perjudicial para el rendimiento.
Los índices en columnas de gran tamaño pueden generar errores:
CREATE TABLE dbo.WideIndex
(
col1 varchar(255) NOT NULL
, col2 varchar(255) NOT NULL
, col3 varchar(600) NOT NULL
);
CREATE INDEX IX_WideIndex_01
ON dbo.WideIndex (col1, col2, col3);
El intento de crear el índice anterior da como resultado esta advertencia:
¡Advertencia! La longitud máxima de la clave es de 900 bytes. El índice ‘IX_WideIndex_01’ tiene una longitud máxima de 1110 bytes. Para alguna combinación de valores grandes, la operación de inserción / actualización fallará.
900 bytes es el tamaño máximo de clave para índices agrupados (e índices no agrupados en SQL Server 2012 y versiones anteriores). 1700 bytes es el tamaño máximo de clave para índices no agrupados en versiones más recientes de SQL Server. Si diseña columnas con un ancho genérico, como (255), puede encontrarse con esta advertencia con mucha más frecuencia de lo esperado.
En caso de que esté interesado en los componentes internos del almacenamiento, puede utilizar la siguiente pequeña prueba para comprender mejor cómo SQL Server almacena los datos de almacenamiento de filas sin comprimir.
Primero, crearemos una tabla donde podamos almacenar columnas de varios tamaños:
IF OBJECT_ID(N'dbo.varchartest', N'U') IS NOT NULL
DROP TABLE dbo.varchartest;
GO
CREATE TABLE dbo.varchartest
(
varchar30 varchar(30) NOT NULL
, varchar255 varchar(255) NOT NULL
, varchar256 varchar(256) NOT NULL
);
Ahora insertaremos una sola fila:
INSERT INTO dbo.varchartest (varchar30, varchar255, varchar256)
VALUES (REPLICATE('1', 30), REPLICATE('2', 255), REPLICATE('3', 256));
Esta consulta utiliza funciones no documentadas y no admitidas. sys.fn_RowDumpCracker y sys.fn_PhyslocCracker para mostrar algunos detalles interesantes sobre la mesa:
SELECT rdc.*
, plc.*
FROM dbo.varchartest vct
CROSS APPLY sys.fn_RowDumpCracker(%%rowdump%%) rdc
CROSS APPLY sys.fn_physlocCracker(%%physloc%%) plc
La salida se verá similar a esto:
╔═════════════════════╦════════════╦═════════╦══════════╦══════════════════════════╦══════════╦═════════════╦═════════════╦═════════╦═════════╦═════════╗ ║ partition_id ║ colName ║ IsInrow ║ IsSparse ║ IsRecordPrefixCompressed ║ IsSymbol ║ PrefixBytes ║ InRowLength ║ file_id ║ page_id ║ slot_id ║ ╠═════════════════════╬════════════╬═════════╬══════════╬══════════════════════════╬══════════╬═════════════╬═════════════╬═════════╬═════════╬═════════╣ ║ 1729382263096344576 ║ varchar30 ║ 1 ║ 0 ║ 0 ║ 0 ║ 0 ║ 30 ║ 1 ║ 1912 ║ 0 ║ ║ 1729382263096344576 ║ varchar255 ║ 1 ║ 0 ║ 0 ║ 0 ║ 0 ║ 255 ║ 1 ║ 1912 ║ 0 ║ ║ 1729382263096344576 ║ varchar256 ║ 1 ║ 0 ║ 0 ║ 0 ║ 0 ║ 256 ║ 1 ║ 1912 ║ 0 ║ ╚═════════════════════╩════════════╩═════════╩══════════╩══════════════════════════╩══════════╩═════════════╩═════════════╩═════════╩═════════╩═════════╝
Como puede ver, el InRowLength para cada valor se muestra, junto con la ubicación de almacenamiento físico de cada fila: “file_id”, “page_id” y “slot_id”.
Si tomamos el file_id y page_id valores de los resultados de la consulta anteriores y ejecutar DBCC PAGE con ellos, podemos ver el contenido real de la página física:
DBCC TRACEON (3604); --send display to the client
DBCC PAGE (tempdb, 1, 1912, 3); --database, file_id, page_id, 3 to show page contents
DBCC TRACEOFF (3604);--reset display back to the error log
Los resultados de mi máquina son:
PAGE: (1:1912) BUFFER: BUF @0x00000000FF5B2E80 bpage = 0x0000000024130000 bhash = 0x0000000000000000 bpageno = (1:1912) bdbid = 2 breferences = 0 bcputicks = 0 bsampleCount = 0 bUse1 = 32497 bstat = 0x10b blog = 0x212121cc bnext = 0x0000000000000000 PAGE HEADER: Page @0x0000000024130000 m_pageId = (1:1912) m_headerVersion = 1 m_type = 1 m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x8000 m_objId (AllocUnitId.idObj) = 98834 m_indexId (AllocUnitId.idInd) = 7936 Metadata: AllocUnitId = 2233785421652951040 Metadata: PartitionId = 1945555045333008384 Metadata: IndexId = 0 Metadata: ObjectId = 34099162 m_prevPage = (0:0) m_nextPage = (0:0) pminlen = 4 m_slotCnt = 1 m_freeCnt = 7538 m_freeData = 652 m_reservedCnt = 0 m_lsn = (35:210971:362) m_xactReserved = 0 m_xdesId = (0:0) m_ghostRecCnt = 0 m_tornBits = 0 DB Frag ID = 1 Allocation Status GAM (1:2) = ALLOCATED SGAM (1:3) = NOT ALLOCATED PFS (1:1) = 0x41 ALLOCATED 50_PCT_FULL DIFF (1:6) = NOT CHANGED ML (1:7) = NOT MIN_LOGGED Slot 0 Offset 0x60 Length 556 Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP VARIABLE_COLUMNS Record Size = 556 Memory Dump @0x000000005145A060 0000000000000000: 30000400 03000003 002d002c 012c0231 31313131 0........-.,.,.11111 0000000000000014: 31313131 31313131 31313131 31313131 31313131 11111111111111111111 0000000000000028: 31313131 31323232 32323232 32323232 32323232 11111222222222222222 000000000000003C: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 0000000000000050: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 0000000000000064: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 0000000000000078: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 000000000000008C: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 00000000000000A0: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 00000000000000B4: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 00000000000000C8: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 00000000000000DC: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 00000000000000F0: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 0000000000000104: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 0000000000000118: 32323232 32323232 32323232 32323232 32323232 22222222222222222222 000000000000012C: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 0000000000000140: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 0000000000000154: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 0000000000000168: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 000000000000017C: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 0000000000000190: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 00000000000001A4: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 00000000000001B8: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 00000000000001CC: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 00000000000001E0: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 00000000000001F4: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 0000000000000208: 33333333 33333333 33333333 33333333 33333333 33333333333333333333 000000000000021C: 33333333 33333333 33333333 33333333 3333333333333333 Slot 0 Column 1 Offset 0xf Length 30 Length (physical) 30 varchar30 = 111111111111111111111111111111 Slot 0 Column 2 Offset 0x2d Length 255 Length (physical) 255 varchar255 = 2222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222 22222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222222 222222222222222222222222222222222222222222 Slot 0 Column 3 Offset 0x12c Length 256 Length (physical) 256 varchar256 = 3333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 33333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 3333333333333333333333333333333333333333333
Otros ya han señalado que el número de bytes necesarios para almacenar la longitud es fijo. Quería centrarme en esta parte de su pregunta:
¿Importa más en este momento?
Tiene su pregunta etiquetada con la edición empresarial, lo que generalmente significa que tendrá una buena cantidad de datos. A menudo, las diferencias de un byte por fila realmente no importan demasiado en la práctica. Por ejemplo, la siguiente tabla con un VARCHAR(255) columna ocupa 143176 KB de espacio en el disco:
DROP TABLE IF EXISTS dbo.V255_FULL;
CREATE TABLE dbo.V255_FULL (
ID1 BIGINT NOT NULL,
ID2 BIGINT NOT NULL,
V255 VARCHAR(255)
);
INSERT INTO dbo.V255_FULL WITH (TABLOCK)
SELECT TOP (500000) 0, 0, REPLICATE('A', 255)
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;
EXEC sp_spaceused 'V255_FULL';
Resultados:
╔═══════════╦══════════════════════╦═══════════╦═══════════╦════════════╦════════╗
║ name ║ rows ║ reserved ║ data ║ index_size ║ unused ║
╠═══════════╬══════════════════════╬═══════════╬═══════════╬════════════╬════════╣
║ V255_FULL ║ 500000 ║ 143176 KB ║ 142888 KB ║ 8 KB ║ 280 KB ║
╚═══════════╩══════════════════════╩═══════════╩═══════════╩════════════╩════════╝
Creemos una segunda tabla con un VARCHAR(256) columna. Eso tomará al menos un byte más por fila, ¿verdad?
DROP TABLE IF EXISTS dbo.V256_FULL;
CREATE TABLE dbo.V256_FULL (
ID1 BIGINT NOT NULL,
ID2 BIGINT NOT NULL,
V256 VARCHAR(256)
);
INSERT INTO dbo.V256_FULL WITH (TABLOCK)
SELECT TOP (500000) 0, 0, REPLICATE('A', 256)
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;
EXEC sp_spaceused 'V256_FULL';
Resultados:
╔═══════════╦══════════════════════╦═══════════╦═══════════╦════════════╦════════╗
║ name ║ rows ║ reserved ║ data ║ index_size ║ unused ║
╠═══════════╬══════════════════════╬═══════════╬═══════════╬════════════╬════════╣
║ V256_FULL ║ 500000 ║ 143176 KB ║ 142888 KB ║ 8 KB ║ 280 KB ║
╚═══════════╩══════════════════════╩═══════════╩═══════════╩════════════╩════════╝
Da la casualidad de que ambas tablas ocupan la misma cantidad de espacio. El mismo número de filas cabe en cada página de 8k. Es genial que desee dedicar tiempo a optimizar su aplicación, pero sospecho que es mejor que se concentre en diferentes áreas.
El tamaño declarado del varchar rara vez tiene un impacto en el rendimiento.1. Los datos pueden almacenarse en realidad como un almacén de filas con compresión de página o de fila. Como un almacén de columnas agrupado o como una tabla optimizada para memoria. Cada uno de estos tendrá diferentes compensaciones de rendimiento, pero nunca importa si declara un varchar (255) o varchar (256).
1 – en circunstancias específicas, existen implicaciones de rendimiento en torno al tamaño de las columnas de caracteres variables; Brent Ozar tiene un gran artículo al respecto aquí.
Si te animas, tienes el poder dejar un ensayo acerca de qué te ha impresionado de este escrito.