Implikacje użycia unikalnego nieklastrowanego indeksu z pokrywającymi kolumnami zamiast klucza podstawowego

Mamy dużą tabelę, [MyTable]która ma obecnie zarówno a Primary Key, jak i jedną Unique Non Clustered Indexw tej samej kolumnie ( [KeyColumn]). Indeks U NC ma również dodatkowe kolumny zakrywające.

Posiadanie zarówno PK, jak i Unikalnego Indeksu NC w tych samych kolumnach wydaje się zbędne, dlatego rozważałem usunięcie Klucza Głównego i zamiast tego użyłem Unikatowego Nieklastrowanego indeksu do celów integralności referencyjnej.

Zauważ, że tabela jest całkowicie skupiona w innej kolumnie.

tzn. mamy:

ALTER TABLE [MyTable]
    ADD CONSTRAINT [PK_MyTable] 
    PRIMARY KEY NONCLUSTERED ([KeyColumn])
GO

I

CREATE UNIQUE NONCLUSTERED INDEX [IX_MyTable_SomeIndex] 
    ON [MyTable] ([KeyColumn]) 
    INCLUDE ([Column1], [Column2])
GO

O ile mi wiadomo, nie można dodawać kolumn zakrywających do klucza podstawowego, więc zamierzam zrobić:

• Usuń zależne od klucza obcego ograniczenia MyTable.KeyColumn
• Upuść MyTable.KeyColumncałkowicie klucz podstawowy
• Ponownie dodaj klucze obce do tabeli (tzn. RI będzie wymuszone przez MyTable.KeyColumn)

Jedyną implikacją, jaką mogę o tym myśleć, jest to, że nie dostaniemy symbolu klucza wizualnego na naszych schematach ERD i że gęstość indeksu (liścia) będzie mniejsza z powodu uwzględnionych kolumn.

Przeczytałem /programming/487314/primary-key-or-unique-index i cieszę się z integralności i wydajności związanych z tym działań.

Moje pytanie brzmi: czy to podejście jest wadliwe?

Edytuj Co próbuję osiągnąć : Optymalizacja wydajności i Wiosenne porządki . Po usunięciu PK lub indeksu, moje indeksy będą wymagały mniej stron = szybsze zapisy, a także korzyści konserwacyjne / operacyjne, tj. Jeden mniej indeksu do defragmentacji itp.

Aby dodać trochę tła, nigdy wcześniej nie miałem tabeli, do której się odwołujemy, bez PK. Jednak fakt, że do tabeli dodano indeks NC z przykrywającymi kolumnami, oznacza, że ​​muszę dostosować swoje myślenie.

Optymalizacja wydajności. Po usunięciu PK lub indeksu, moje indeksy będą wymagały mniej stron = szybsze zapisy, a także korzyści konserwacyjne / operacyjne, tj. Jeden mniej indeksu do defragmentacji itp.

Musisz być w stanie udowodnić, że to, co jest proponowane, rzeczywiście pomoże (koszt vs. korzyść). Z jakiego powodu rozważana jest ta zmiana? Czy rzeczywiście występują problemy z wydajnością tej tabeli, czy po prostu „wyglądają źle”?

Oto kilka innych pytań, które pomogą Ci podjąć najlepszą decyzję dla twojego środowiska:

• Ile czasu można by zaoszczędzić w oknie konserwacji? W oknie kopii zapasowej?

• Ile miejsca to zaoszczędziłoby (pliki danych, pliki dziennika, kopie zapasowe itp.)?

• Czy INSERTwydajność na tym stole jest teraz naprawdę wąskim gardłem? Ile by to poprawiło? Czy usunięcie indeksu jest najlepszą strategią, aby rozwiązać ten problem?

• Czy spowoduje to problemy z narzędziami i strukturami baz danych (szczególnie ORM), które oczekują, że każda tabela będzie miała klucz podstawowy, a nie tylko unikalny indeks? Replikacja transakcyjna wymaga klucza podstawowego w opublikowanych tabelach.

• Czy ważny jest samodokumentujący schemat bazy danych?

• Mimo ograniczonego wykorzystania, czy zawężenie indeksu klucza głównego nadal pozwala optymalizatorowi na tworzenie bardziej wydajnych planów dla niektórych zapytań? (Użyj, sys.dm_db_index_usage_statsaby się dowiedzieć.)

Osobiście, z tego, co nam powiedziałeś, zostawiłbym to w spokoju, dopóki nie zostanie udowodnione, że zarówno (a) dodatkowy indeks stanowi problem, a (b) usunięcie go jest rozwiązaniem.

Jedynym rodzajem zapytania w tej tabeli, który będzie działał gorzej (i tylko nieco gorzej), będą te, które żądają zakresu wartości KeyColumn - ponieważ te zapytania najlepiej byłoby teraz obsłużyć przez wyszukiwanie indeksu w twoim PK.

Warto pamiętać, że koszt sprawdzania integralności referencyjnej dla tabel, które odnoszą się do tej tabeli, będzie wyższy (ponownie tylko nieznacznie wyższy).

Tak długo, jak dbasz o aspekt zerowy, powinieneś być w porządku z jednym indeksem.

Gdyby to był mój DB, prawdopodobnie wybrałbym pojedynczy unikalny indeks, wszystkie inne rzeczy byłyby równe.

O ile mi wiadomo, nie można dodawać kolumn zakrywających do klucza podstawowego

Jeśli masz indeks klastrowy w KeyColumn, ponieważ jest to indeks klastrowany, wszystkie pozostałe kolumny są domyślnie „zakryte”. Więc nic nie zyskujesz, dodając kolejny indeks do KeyColumn. W rzeczywistości spowolnisz wkładki i zużyjesz więcej miejsca.

Wynika to z faktu, że indeks klastrowany nie jest indeksem jako takim, lecz jedynie instrukcją do przechowywania wierszy tabeli w kolejności indeksu. A kiedy już znajdziesz wiersz po kluczu podstawowym, masz już wszystkie inne kolumny.