Чому оператор агрегату використовується після унікального сканування індексу

У мене є таблиця з унікальним відфільтрованим індексом для ненульових значень. У плані запитів є використання різних. Чи є для цього причина?

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). За інших обставин жоден із цих підходів не підходить.