Do przechowywania 128-bitowego identyfikatora UUID istnieje wiele opcji przechowywania:
- kolumna bajtowa [16]
- dwie kolumny bigint / long (64 bity)
- kolumna CHAR (36) - 32 cyfry szesnastkowe + 4 myślniki.
- kolumna specyficzna dla bazy danych UUID, jeśli db ją obsługuje
Które z nich są najbardziej wydajne z punktu widzenia indeksowania? Jeśli db nie obsługuje dedykowanego typu UUID, które z 1, 2, 3 są najlepszymi kandydatami?
sql-server
mysql
oracle
postgresql
index
Vlad Mihalcea
źródło
źródło
raw(16)w Oracle iuuidPostgreSQL.uuid>>bytea>>textzCHECKograniczeniem>varchar(36)>>char(36). Zobacz: dba.stackexchange.com/a/89433/3684 i dba.stackexchange.com/a/115316/3684 .Odpowiedzi:
Dedykowany
uuidtyp jest najlepszym wyborem dla PostgreSQL. Trudno powiedzieć z innymi bazami danych - nie jest niemożliwe, aby ktoś wszczepił auuidtyp, który jest przechowywany mniej wydajnie niż zwykły typ bajtu.Ponownie w PostgreSQL
byteabyłby rozsądny sposób przechowywania UUID, gdybyś nie miał tegouuidtypu. W przypadku innych baz danych zależy to od sposobu przechowywania danych binarnych.Tam, gdzie to możliwe, zdecydowanie unikałbym używania heksów z myślnikami. Porównywanie, sortowanie i przechowywanie jest znacznie mniej wydajne.
Tak naprawdę „nie (2) lub (3)”. Zawsze. Użyj (4) tam, gdzie jest to obsługiwane, (1) w przeciwnym razie.
źródło
SELECT ARRAY['ef1e0638-072e-4caa-88b3-97bfa5b2e8c3']::uuid[]W kolejności preferencji: 4,1,2,3 Nie używaj UUID jako klucza klastrowania, jeśli używasz serwera SQL, ponieważ nie tylko źle fragmentuje, klucz klastrowania jest używany we wszystkich indeksach nieklastrowanych i dodajesz te bajty do każdy wiersz indeksu. Fragmentację można złagodzić za pomocą NEWSEQUENTIALID, ale zwykle wolą tożsamość bingint dla Twojego klucza klastrowania niż GUID, aby zapobiec wzdęciom w innych indeksach.
Różnica między wyborem 1 na 2 zależy od tego, jak bardziej wydajna baza danych obsługuje dwie kolumny podstawowych typów w stosunku do stałej kolumny z jedną kolumną. Testowanie przy użyciu fałszywych danych powinno być dość łatwe. Sprawdź szybkość swoich zapytań, a także rozmiar indeksów i danych. Mały + szybki jest najlepszy!
źródło
Należy przypuszczać, że każdy typ danych obsługiwany natywnie byłby lepiej zoptymalizowany w produkcie niż cokolwiek, co można by połączyć jako klienta tego produktu. Następnie cokolwiek ma najmniejszą liczbę bajtów, więc uzyskuje się maksymalną liczbę wierszy na stronę.
źródło