Dlaczego operator agregujący jest używany po unikalnym skanie indeksu

Mam tabelę z unikalnym indeksem filtrowanym pod kątem wartości, które nie mają wartości zerowej. W planie zapytań jest stosowane odrębne. Czy jest tego powód?

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  

plan zapytania:

Jest to znane ograniczenie optymalizatora zapytań programu SQL Server. Zgłoszono to do firmy Microsoft, ale element Połącz (nie jest już dostępny) został zamknięty. Nie zostanie naprawiony.

Istnieją dodatkowe konsekwencje tego ograniczenia, w tym niektóre, o których pisałem w Ograniczeniach optymalizatora z filtrowanymi indeksami , podsumowanie jest cytowane poniżej:

W tym poście podkreślono dwa ważne ograniczenia optymalizatora z filtrowanymi indeksami:

• Nadmiarowe predykaty łączenia mogą być konieczne do dopasowania przefiltrowanych indeksów
• Filtrowane indeksy unikalne nie dostarczają optymalizatorowi informacji o niepowtarzalności

W niektórych przypadkach może być praktyczne dodanie po prostu nadmiarowych predykatów do każdego zapytania. Alternatywą jest hermetyzacja pożądanych domniemanych predykatów w nieindeksowanym widoku. Plan dopasowania skrótu w tym poście był znacznie lepszy niż plan domyślny, mimo że optymalizator powinien być w stanie znaleźć nieco lepszy plan łączenia scalania. Czasami może być konieczne zaindeksowanie widoku i użycie NOEXPANDpodpowiedzi (i tak wymagane w przypadku instancji Standard Edition). W jeszcze innych okolicznościach żadne z tych podejść nie będzie odpowiednie.