Чому відфільтрований індекс за значенням IS NULL не використовується?

Припустимо, у нас є таке визначення таблиці:

CREATE TABLE MyTab (
    ID INT IDENTITY(1,1) CONSTRAINT PK_MyTab_ID PRIMARY KEY
    ,GroupByColumn NVARCHAR(10) NOT NULL
    ,WhereColumn DATETIME NULL
    )

І відфільтрований некластеризований індекс на зразок цього:

CREATE NONCLUSTERED INDEX IX_MyTab_GroupByColumn ON MyTab 
    (GroupByColumn)
WHERE (WhereColumn IS NULL) 

Чому цей показник не "охоплює" цей запит:

SELECT 
    GroupByColumn
    ,COUNT(*)
FROM MyTab
WHERE WhereColumn IS NULL
GROUP BY GroupByColumn

Я отримую такий план виконання:

KeyLookup призначений для предиката WhereColumn IS NULL.

Ось план: https://www.brentozar.com/pastetheplan/?id=SJcbLHxO7

Чому цей показник не "охоплює" цей запит:

Немає вагомих причин. Це індекс покриття для цього запиту.

Будь ласка, проголосуйте за пункт відшкодування тут: https://feedback.azure.com/forums/908035-sql-server/suggestions/32896348-filtered-index-not-used-when-is-null-and-key-looku

І як вирішення включіть WhereColumnу відфільтрований індекс:

CREATE NONCLUSTERED INDEX IX_MyTab_GroupByColumn 
ON MyTab (GroupByColumn) include (WhereColumn)
WHERE (WhereColumn IS NULL) 

У мене була така ж проблема, яку я думаю, коли робив тестування тижнів тому. У мене є запит з первинним предикатом, який вимагає, щоб результати, що повертаються, мали час закриття NULL, і я подумав про використання відфільтрованого індексу, оскільки 25K 2M + записів - NULL, і ця цифра скоро зменшиться.

Відфільтрований індекс не звик - я припускав, що через "не унікальність" або спільність - поки я не знайшов статтю підтримки Microsoft, яка говорить:

Щоб вирішити цю проблему, включіть стовпець, який тестується як NULL, у повернених стовпцях. Або додайте цей стовпець як включення стовпців до індексу.

Отже, додавання стовпця до індексу (або включення), здається, є офіційною відповіддю MS.