UWAGA: Ta odpowiedź dotyczy tworzenia oprogramowania dla dużych przedsiębiorstw .
Jest to problem RDBMS, a nie tylko SQL Server, a zachowanie może być bardzo interesujące. Po pierwsze, chociaż klucze podstawowe są indeksowane automatycznie (unikalnie), NIE jest to bezwzględne. Są chwile, kiedy konieczne jest, aby klucz podstawowy NIE był jednoznacznie indeksowany.
W większości systemów RDBMS unikatowy indeks zostanie automatycznie utworzony na kluczu podstawowym, jeśli jeszcze nie istnieje . Dlatego można utworzyć własny indeks w kolumnie klucza podstawowego przed zadeklarowaniem go jako klucza podstawowego, a następnie ten indeks będzie używany (jeśli jest to dopuszczalne) przez aparat bazy danych podczas stosowania deklaracji klucza podstawowego. Często można utworzyć klucz podstawowy i zezwolić na utworzenie jego domyślnego unikatowego indeksu, a następnie utworzyć własny indeks alternatywny w tej kolumnie, a następnie usunąć indeks domyślny.
A teraz zabawna część - kiedy NIE potrzebujesz unikalnego indeksu klucza podstawowego? Nie chcesz jednego i nie możesz go tolerować, gdy twoja tabela zbiera wystarczającą ilość danych (wierszy), aby utrzymanie indeksu było zbyt kosztowne. Różni się to w zależności od sprzętu, silnika RDBMS, charakterystyki tabeli i bazy danych oraz obciążenia systemu. Jednak zwykle zaczyna się manifestować, gdy tabela osiągnie kilka milionów wierszy.
Zasadniczą kwestią jest to, że każde wstawienie wiersza lub aktualizacja kolumny klucza podstawowego powoduje skanowanie indeksu w celu zapewnienia unikalności. To unikalne skanowanie indeksu (lub jego odpowiednik w jakimkolwiek RDBMS) staje się znacznie droższe wraz ze wzrostem tabeli, aż zdominuje wydajność tabeli.
Wielokrotnie zajmowałem się tym problemem w przypadku tabel o wielkości nawet dwóch miliardów wierszy, 8 TB pamięci masowej i czterdziestu milionów wstawianych wierszy dziennie. Otrzymałem zadanie przeprojektowania systemu, który obejmował porzucenie unikalnego indeksu klucza podstawowego praktycznie w pierwszym kroku. Rzeczywiście, obniżenie tego wskaźnika było konieczne w produkcji po prostu po to, aby odzyskać siły po przerwie, zanim jeszcze zbliżyliśmy się do przeprojektowania. To przeprojektowanie obejmowało znalezienie innych sposobów zapewnienia niepowtarzalności klucza podstawowego i zapewnienia szybkiego dostępu do danych.