Épargnant
Lorsque vous effectuez des tests sur des colonnes éparses, comme vous le faites, il y a eu un ralentissement des performances dont je voudrais connaître la cause directe.
DDL
J'ai créé deux tables identiques, une avec 4 colonnes éparses et une sans colonnes éparses.
--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
J'ai ensuite inséré environ 2540 valeurs NON NULL dans les deux.
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;
Ensuite, j'ai inséré des valeurs NULL 1M dans les deux tableaux
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;
Requêtes
Exécution de table sans analyse
Lors de l'exécution de cette requête deux fois sur la table non analysée nouvellement créée:
SET STATISTICS IO, TIME ON;
SELECT * FROM dbo.nonsparse
WHERE 1= (SELECT 1) -- force non trivial plan
OPTION(RECOMPILE,MAXDOP 1);
Les lectures logiques montrent 5257 pages
(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.
Et le temps processeur est à 343 ms
SQL Server Execution Times:
CPU time = 343 ms, elapsed time = 3850 ms.
exécution de table clairsemée
Exécution de la même requête deux fois sur la table clairsemée:
SELECT * FROM dbo.sparse
WHERE 1= (SELECT 1) -- force non trivial plan
OPTION(RECOMPILE,MAXDOP 1);
Les lectures sont plus basses, 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.
Mais le temps processeur est plus élevé, 547 ms .
SQL Server Execution Times:
CPU time = 547 ms, elapsed time = 2406 ms.
Plan d'exécution de table éparse
plan d'exécution de table non éparse
Des questions
Question d'origine
Étant donné que les valeurs NULL ne sont pas stockées directement dans les colonnes clairsemées, l'augmentation du temps processeur pourrait-elle être due au retour des valeurs NULL en tant qu'ensemble de résultats? Ou s'agit-il simplement du comportement indiqué dans la documentation ?
Des colonnes éparses réduisent l'espace requis pour les valeurs nulles au prix de plus de surcharge pour récupérer les valeurs non nulles
Ou les frais généraux sont-ils uniquement liés aux lectures et au stockage utilisés?
Même lors de l'exécution de ssms avec les résultats de suppression après l'option d'exécution, le temps processeur de la sélection clairsemée était plus élevé (407 ms) par rapport à la non clairsemée (219 ms).
ÉDITER
C'était peut-être le surcoût des valeurs non nulles, même s'il n'y en a que 2540, mais je ne suis toujours pas convaincu.
Cela semble être à peu près la même performance, mais le facteur clairsemé a été perdu.
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);
Semble avoir à peu près le même temps d'exécution:
SQL Server Execution Times:
CPU time = 297 ms, elapsed time = 292 ms.
SQL Server Execution Times:
CPU time = 281 ms, elapsed time = 319 ms.
Mais pourquoi les lectures logiques ont-elles le même montant maintenant? L'index filtré de la colonne clairsemée ne devrait-il pas stocker quoi que ce soit, à l'exception du champ ID inclus et d'autres pages non liées aux données?
Table 'sparse'. Scan count 1, logical reads 5785,
Table 'nonsparse'. Scan count 1, logical reads 5785
Et la taille des deux indices:
RowCounts Used_MB Unused_MB Total_MB
1000000 45.20 0.06 45.26Pourquoi sont-ils de la même taille? La rareté a-t-elle été perdue?
Les deux plans de requête lors de l'utilisation de l'index filtré
Informaitons supplémentaires
select @@versionMicrosoft SQL Server 2017 (RTM-CU16) (KB4508218) - 14.0.3223.3 (X64) 12 juillet 2019 17:43:08 Copyright (C) 2017 Microsoft Corporation Developer Edition (64-bit) sur Windows Server 2012 R2 Datacenter 6.3 (Build 9600:) (Hyperviseur)
Lors de l'exécution des requêtes et de la sélection du champ ID uniquement , le temps processeur est comparable, avec des lectures logiques inférieures pour la table clairsemée.
Taille des tables
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.14Lors du forçage de l'index cluster ou non cluster, la différence de temps CPU reste.
