W projektowaniu bazy danych często używamy guid lub int jako klucza głównego, a na podstawie zdobytej wiedzy zawsze uważaliśmy, że int jest bardziej efektywny jako klucz główny, ale jest to niemożliwe bez starannego testowania
Wyjaśnij powód. Zdarzyło się, że podczas optymalizacji bazy danych napotkałem ten problem, więc przeprowadziłem test.
Środowisko testowe:
Komputer stacjonarny Pentiun(R) 4 CPU 3.06GHz Win XP Professional 1,5G DDR RAM SQL Server 2005 Personal
Proces testowania:
Najpierw stwórz bazę testową, Testuj
Wyniki testów są następujące:
Jak wspomniano powyżej, efektywność używania int jako klucza głównego jest lepsza w porównaniu z użyciem guid jako klucza głównego, zwłaszcza gdy pojawia się zapytanie o połączenie i usuwanie rekordów.
Co więcej, w dzisiejszym zapytaniu danych z głównym kluczem w GUID timeout zapytania wielokrotnie występował z powodu zagnieżdżania kilku wyników podzapytań. Dlatego jestem za użyciem int jako klucza głównego i nie zgadzam się z guid jako kluczem głównym. Powyższe poglądy odzwierciedlają osobiste opinie, a każdy jest mile widziany do wyrażania swoich opinii oraz wyjaśniania zalet i wad guid and int jako głównych kluczy.
Badania kontrolne:
Po przypomnieniu przez braci, dziś do dwóch podtabel dodano indeks nieskupiony:
UTWORZENIE NIEKLASTEROWANEGO INDEKSU Index_Detail_Guid NA Test_Guid_Detail(GID) UTWORZENIE NIEKLASTROWANEGO INDEKSU Index_Detail_id na Test_Int_Detail(id) Następnie przeprowadziłem wewnętrzne zapytanie o połączenie i okazało się, że jak powiedział @Xu Shaoxia, efektywność rzeczywiście nie jest na tyle oczywista, by wskazać na więcej niż 50%, a zasadniczo tylko około 23% poprawy, co nadal jest akceptowalne.
Dlatego jest zalecany
1. W systemach, które często wymagają migracji danych, zaleca się używanie Guid. A dodawanie indeksów nieklastrowanych do odpowiadających pol klucza obcego, czyli pol używanych do zapytań o połączenia, przynosi ogromne korzyści dla poprawy wydajności. Pole warunku gdzie można również dodać w odpowiednim przypadku dla indeksów nieskupionych.
2. Używając typu Guid jako klucza głównego, typ danych powinien być unikalnym identyfikatorem i pamiętaj, aby anulować "indeks agregatywny" klucza głównego
3. W systemach, które nie wymagają migracji lub małych systemach, nadal bardzo wygodne jest użycie int jako klucza głównego, a wydajność jest pewna poprawa.
|