Supposons que nous ayons une définition de table comme celle-ci:
CREATE TABLE MyTab (
ID INT IDENTITY(1,1) CONSTRAINT PK_MyTab_ID PRIMARY KEY
,GroupByColumn NVARCHAR(10) NOT NULL
,WhereColumn DATETIME NULL
)
Et un index non cluster filtré comme celui-ci:
CREATE NONCLUSTERED INDEX IX_MyTab_GroupByColumn ON MyTab
(GroupByColumn)
WHERE (WhereColumn IS NULL)
Pourquoi cet index ne "couvre" pas cette requête:
SELECT
GroupByColumn
,COUNT(*)
FROM MyTab
WHERE WhereColumn IS NULL
GROUP BY GroupByColumn
Je reçois ce plan d'exécution:
Le KeyLookup est pour le prédicat WhereColumn IS NULL.
Voici le plan: https://www.brentozar.com/pastetheplan/?id=SJcbLHxO7
Pourquoi cet index ne "couvre" pas cette requête:
Aucune bonne raison. Il s'agit d'un index de couverture pour cette requête.
Veuillez voter pour l'article de retour ici: https://feedback.Azure.com/forums/908035-sql-server/suggestions/32896348-filtered-index-not-used-when-is-null-and- key-look
Et comme solution de contournement inclure le WhereColumn
dans l'index filtré:
CREATE NONCLUSTERED INDEX IX_MyTab_GroupByColumn
ON MyTab (GroupByColumn) include (WhereColumn)
WHERE (WhereColumn IS NULL)
J'ai eu le même problème, je pense, lors de tests il y a des semaines. J'ai une requête avec un prédicat principal qui nécessite que les résultats retournés aient une heure fermée NULL et j'ai pensé à utiliser un index filtré car 25K d'enregistrements 2M + sont NULL et ce chiffre diminuera très bientôt.
L'index filtré n'a pas été utilisé - j'ai supposé en raison de la `` non-unicité '' ou de la similitude - jusqu'à ce que je trouve un article de support Microsoft qui dit:
Pour résoudre ce problème, incluez la colonne testée comme NULL dans les colonnes renvoyées. Ou, ajoutez cette colonne en tant que colonnes d'inclusion dans l'index.
L'ajout de la colonne à l'index (ou à l'inclusion) semble donc être la réponse officielle des États membres.