Почему оператор агрегирования используется после сканирования уникального индекса

У меня есть таблица с уникальным индексом, отфильтрованным для ненулевых значений. В плане запроса есть использование различных. Есть причина для этого?

USE tempdb

CREATE TABLE T1( Id INT NOT NULL  IDENTITY PRIMARY KEY ,F1 INT , F2 INT )
go
CREATE UNIQUE NONCLUSTERED INDEX UK_T1 ON T1 (F1,F2) WHERE F1 IS NOT NULL AND F2 IS NOT NULL 
GO
INSERT INTO  T1(f1,F2) VALUES(1,1),(1,2),(2,1)

SELECT DISTINCT   F1,F2 FROM T1 WHERE F1 IS NOT NULL AND F2 IS NOT NULL 
SELECT  F1,F2 FROM T1 WHERE F1 IS NOT NULL AND F2 IS NOT NULL  

план запроса:

Это известное ограничение оптимизатора запросов SQL Server. Microsoft сообщила об этом, но элемент Connect (более недоступный) был закрыт. Не удается исправить.

Существуют дополнительные последствия этого ограничения, в том числе те, о которых я писал в разделе «Ограничения оптимизатора с отфильтрованными индексами» , резюме приведено ниже:

В этом посте освещаются два важных ограничения оптимизатора с отфильтрованными индексами:

• Избыточные предикаты объединения могут быть необходимы для соответствия фильтруемым индексам
• Отфильтрованные уникальные индексы не предоставляют оптимизатору информацию об уникальности

В некоторых случаях может оказаться целесообразным просто добавить избыточные предикаты к каждому запросу. Альтернативой является инкапсуляция желаемых подразумеваемых предикатов в неиндексированном представлении. План соответствия хеш-функции в этом посте был намного лучше, чем план по умолчанию, хотя оптимизатор должен был найти немного лучший план объединения слиянием. Иногда вам может понадобиться проиндексировать представление и использовать NOEXPANDподсказки (в любом случае требуется для экземпляров Standard Edition). В других обстоятельствах ни один из этих подходов не будет подходящим.