Sparring
Al hacer algunas pruebas en columnas dispersas, como lo hace, hubo un retroceso en el rendimiento del que me gustaría saber la causa directa.
DDL
Creé dos tablas idénticas, una con 4 columnas dispersas y otra sin columnas dispersas.
--Non Sparse columns table & NC index
CREATE TABLE dbo.nonsparse( ID INT IDENTITY(1,1) PRIMARY KEY NOT NULL,
charval char(20) NULL,
varcharval varchar(20) NULL,
intval int NULL,
bigintval bigint NULL
);
CREATE INDEX IX_Nonsparse_intval_varcharval
ON dbo.nonsparse(intval,varcharval)
INCLUDE(bigintval,charval);
-- sparse columns table & NC index
CREATE TABLE dbo.sparse( ID INT IDENTITY(1,1) PRIMARY KEY NOT NULL,
charval char(20) SPARSE NULL ,
varcharval varchar(20) SPARSE NULL,
intval int SPARSE NULL,
bigintval bigint SPARSE NULL
);
CREATE INDEX IX_sparse_intval_varcharval
ON dbo.sparse(intval,varcharval)
INCLUDE(bigintval,charval);DML
Luego inserté unos 2540 valores NO NULOS en ambos.
INSERT INTO dbo.nonsparse WITH(TABLOCK) (charval, varcharval,intval,bigintval)
SELECT 'Val1','Val2',20,19
FROM MASTER..spt_values;
INSERT INTO dbo.sparse WITH(TABLOCK) (charval, varcharval,intval,bigintval)
SELECT 'Val1','Val2',20,19
FROM MASTER..spt_values;Luego, inserté 1M valores NULL en ambas tablas
INSERT INTO dbo.nonsparse WITH(TABLOCK) (charval, varcharval,intval,bigintval)
SELECT TOP(1000000) NULL,NULL,NULL,NULL
FROM MASTER..spt_values spt1
CROSS APPLY MASTER..spt_values spt2;
INSERT INTO dbo.sparse WITH(TABLOCK) (charval, varcharval,intval,bigintval)
SELECT TOP(1000000) NULL,NULL,NULL,NULL
FROM MASTER..spt_values spt1
CROSS APPLY MASTER..spt_values spt2;Consultas
Ejecución de tabla no dispersa
Al ejecutar esta consulta dos veces en la tabla no dispersa recién creada:
SET STATISTICS IO, TIME ON;
SELECT * FROM dbo.nonsparse
WHERE 1= (SELECT 1) -- force non trivial plan
OPTION(RECOMPILE,MAXDOP 1);Las lecturas lógicas muestran 5257 páginas.
(1002540 rows affected)
Table 'nonsparse'. Scan count 1, logical reads 5257, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.Y el tiempo de CPU es de 343 ms
SQL Server Execution Times:
CPU time = 343 ms, elapsed time = 3850 ms.ejecución de tabla dispersa
Ejecutando la misma consulta dos veces en la tabla dispersa:
SELECT * FROM dbo.sparse
WHERE 1= (SELECT 1) -- force non trivial plan
OPTION(RECOMPILE,MAXDOP 1);Las lecturas son más bajas, 1763.
(1002540 rows affected)
Table 'sparse'. Scan count 1, logical reads 1763, physical reads 3, read-ahead reads 1759, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.Pero el tiempo de CPU es mayor, 547 ms .
SQL Server Execution Times:
CPU time = 547 ms, elapsed time = 2406 ms.Plan de ejecución de tabla dispersa
plan de ejecución de tabla no dispersa
Preguntas
Pregunta original
Dado que los valores NULL no se almacenan directamente en las columnas dispersas, ¿podría el aumento en el tiempo de CPU deberse a devolver los valores NULL como un conjunto de resultados? ¿O es simplemente el comportamiento como se señala en la documentación ?
Las columnas dispersas reducen los requisitos de espacio para valores nulos a costa de más gastos generales para recuperar valores no nulos
¿O la sobrecarga solo está relacionada con las lecturas y el almacenamiento utilizado?
Incluso cuando se ejecutan ssms con los resultados de descarte después de la opción de ejecución, el tiempo de CPU de la selección dispersa fue mayor (407 ms) en comparación con el no disperso (219 ms).
EDITAR
Podría haber sido la sobrecarga de los valores no nulos, incluso si solo hay 2540 presentes, pero todavía no estoy convencido.
Esto parece tener el mismo rendimiento, pero se perdió el factor escaso.
CREATE INDEX IX_Filtered
ON dbo.sparse(charval,varcharval,intval,bigintval)
WHERE charval IS NULL
AND varcharval IS NULL
AND intval IS NULL
AND bigintval IS NULL;
CREATE INDEX IX_Filtered
ON dbo.nonsparse(charval,varcharval,intval,bigintval)
WHERE charval IS NULL
AND varcharval IS NULL
AND intval IS NULL
AND bigintval IS NULL;
SET STATISTICS IO, TIME ON;
SELECT charval,varcharval,intval,bigintval FROM dbo.sparse WITH(INDEX(IX_Filtered))
WHERE charval IS NULL AND varcharval IS NULL
AND intval IS NULL
AND bigintval IS NULL
OPTION(RECOMPILE,MAXDOP 1);
SELECT charval,varcharval,intval,bigintval
FROM dbo.nonsparse WITH(INDEX(IX_Filtered))
WHERE charval IS NULL AND
varcharval IS NULL
AND intval IS NULL
AND bigintval IS NULL
OPTION(RECOMPILE,MAXDOP 1);Parece tener aproximadamente el mismo tiempo de ejecución:
SQL Server Execution Times:
CPU time = 297 ms, elapsed time = 292 ms.
SQL Server Execution Times:
CPU time = 281 ms, elapsed time = 319 ms.Pero, ¿por qué las lecturas lógicas son la misma cantidad ahora? ¿No debería el índice filtrado para la columna dispersa no almacenar nada excepto el campo ID incluido y algunas otras páginas sin datos?
Table 'sparse'. Scan count 1, logical reads 5785,
Table 'nonsparse'. Scan count 1, logical reads 5785Y el tamaño de ambos índices:
RowCounts Used_MB Unused_MB Total_MB
1000000 45.20 0.06 45.26¿Por qué son del mismo tamaño? ¿Se perdió la escasez?
Ambos planes de consulta cuando se utiliza el índice filtrado
Información extra
select @@versionMicrosoft SQL Server 2017 (RTM-CU16) (KB4508218) - 14.0.3223.3 (X64) 12 de julio de 2019 17:43:08 Copyright (C) 2017 Microsoft Corporation Developer Edition (64 bits) en Windows Server 2012 R2 Datacenter 6.3 (Build 9600:) (hipervisor)
Mientras ejecuta las consultas y solo selecciona el campo ID , el tiempo de CPU es comparable, con lecturas lógicas más bajas para la tabla dispersa.
Tamaño de las mesas
SchemaName TableName RowCounts Used_MB Unused_MB Total_MB
dbo nonsparse 1002540 89.54 0.10 89.64
dbo sparse 1002540 27.95 0.20 28.14Al forzar el índice agrupado o no agrupado, la diferencia de tiempo de la CPU permanece.
