Skip to content

Generator UUID i dekoder — v1, v4, v5, v7 z trybem wsadowym

Generator UUID — twórz identyfikatory v1, v4, v5 i v7 natychmiast. Dekoduj i waliduj UUID. Wsadowo do 50. W 100% w przeglądarce.

Bez śledzenia Działa w przeglądarce Bezpłatne
Wszystkie UUID są generowane lokalnie w przeglądarce. Nic nie jest przesyłane ani przechowywane.
Zweryfikowano pod kątem zgodności z RFC 9562 i poprawności strukturalnej — Zespół inżynieryjny Go Tools · Mar 22, 2026

Czym jest UUID?

UUID (Universally Unique Identifier) to 128-bitowy globalnie unikalny identyfikator znormalizowany przez RFC 9562 (IETF, maj 2024), zaprojektowany do generowania bezkolizyjnych identyfikatorów w systemach rozproszonych bez centralnej koordynacji. UUID to najszerzej stosowany format identyfikatora w nowoczesnym oprogramowaniu — wykorzystywany w kluczach głównych baz danych, śledzeniu żądań API, zarządzaniu sesjami oraz architekturach mikrousług.

UUID zapisuje się jako 32 cyfry szesnastkowe w kanonicznym formacie 8-4-4-4-12, na przykład `550e8400-e29b-41d4-a716-446655440000`. Specyfikację utrzymuje IETF; RFC 9562 zastępuje wcześniejsze RFC 4122 (2005) i formalnie wprowadza wersje UUID 6, 7 oraz 8.

W powszechnym użyciu jest pięć wersji UUID. Wersja 1 (v1) koduje bieżący timestamp i adres MAC maszyny generującej, dzięki czemu każdy UUID jest unikalny w czasie i przestrzeni. Wersje 3 (v3) i 5 (v5) są deterministyczne — hashują przestrzeń nazw oraz nazwę odpowiednio za pomocą MD5 lub SHA-1, zawsze dając ten sam UUID dla tych samych danych wejściowych. Wersja 4 (v4) jest najczęstsza: wypełnia 122 bity kryptograficznie bezpiecznymi danymi losowymi, dając ponad 5,3 × 10³⁶ możliwych wartości (RFC 9562, sekcja 5.4). Wersja 7 (v7) to najnowszy standard: jak stwierdza RFC 9562 w sekcji 5.7, „UUID w wersji 7 zawiera pole wartości uporządkowane czasowo, wyprowadzone z powszechnie zaimplementowanego i dobrze znanego źródła timestamp opartego na epoce Unix” — łącząc 48-bitowy timestamp w milisekundach z danymi losowymi w celu uzyskania UUID, które są jednocześnie unikalne i naturalnie sortowalne według czasu utworzenia.

UUID są niezbędne w systemach rozproszonych, bazach danych, API oraz wszędzie tam, gdzie potrzebne są unikalne identyfikatory bez scentralizowanej koordynacji. Eliminują ryzyko kolizji identyfikatorów między niezależnymi systemami, dzięki czemu doskonale sprawdzają się w mikrousługach, event sourcing oraz architekturach wielodostępnych.

Narzędzie generuje wszystkie wersje UUID w całości w przeglądarce za pomocą Web Crypto API — żaden UUID nie jest przesyłany na serwer. W przeciwieństwie do generatorów serwerowych nie ma tu przesyłania danych, logowania ani ich przechowywania. Można bezpiecznie używać go do produkcyjnych kluczy baz danych, identyfikatorów API oraz aplikacji o podwyższonych wymaganiach bezpieczeństwa. Można także dekodować i walidować istniejące UUID, aby sprawdzić ich wersję, wariant oraz osadzone dane.

UUID są ściśle powiązane z innymi prymitywami programistycznymi. UUID v1 i v7 osadzają bezpośrednio timestamp Unix, UUID v3 i v5 wykorzystują hash MD5 i SHA-1 jako fundament, a ciągi UUID są często przesyłane wewnątrz payload-ów JSON, które najlepiej oglądać w narzędziu do formatowania JSON. Pełne wprowadzenie do formatu, wersji i praktycznych zastosowań UUID znajduje się w naszym kompletnym przewodniku po UUID. Przy wyborze między UUID v4, v7, ULID a Snowflake jako kluczem głównym bazy danych warto sięgnąć po nasze porównanie identyfikatorów.

// Generate a UUID v4 using the Web Crypto API
const uuid = crypto.randomUUID();
console.log(uuid);
// → '550e8400-e29b-41d4-a716-446655440000'

// Manual v4 generation with crypto.getRandomValues()
function generateUUIDv4() {
  const bytes = new Uint8Array(16);
  crypto.getRandomValues(bytes);
  bytes[6] = (bytes[6] & 0x0f) | 0x40; // version 4
  bytes[8] = (bytes[8] & 0x3f) | 0x80; // variant 10
  const hex = Array.from(bytes, b => b.toString(16).padStart(2, '0')).join('');
  return `${hex.slice(0,8)}-${hex.slice(8,12)}-${hex.slice(12,16)}-${hex.slice(16,20)}-${hex.slice(20)}`;
}

Najważniejsze funkcje

Wsparcie dla UUID v7 (RFC 9562)

Generuje najnowszy format UUID v7 z osadzonym timestamp Unix dla uporządkowanych czasowo identyfikatorów przyjaznych bazom danych. Jedno z nielicznych narzędzi online wspierających standard RFC 9562.

Dekoder i walidator UUID

Parsuje dowolny UUID, aby ujawnić jego wersję, wariant, timestamp (v1/v7), sekwencję zegara oraz informacje o węźle. Natychmiast sprawdza, czy ciąg ma poprawnie sformatowany UUID.

Wsparcie dla wielu wersji

Generuje UUID w pięciu wersjach — v1 (czasowy), v3 (MD5), v4 (losowy), v5 (SHA-1) oraz v7 (losowy uporządkowany czasowo) — wszystkie zgodne z RFC 9562.

Generowanie wsadowe

Pozwala wygenerować jednorazowo do 50 unikalnych UUID. Każdy powstaje niezależnie z pełną losowością kryptograficzną lub poprawnym kodowaniem właściwym dla wersji.

Wiele formatów wyjściowych

Wynik można uzyskać w formacie standardowym małymi literami, WIELKIMI LITERAMI, bez myślników lub w nawiasach klamrowych {GUID} — pasującym do dokładnego formatu wymaganego przez system lub framework.

Bezpieczeństwo kryptograficzne

Wykorzystuje Web Crypto API (crypto.getRandomValues()) do prawdziwie losowego generowania liczb — ten sam standard, który stosują nowoczesne przeglądarki i narzędzia bezpieczeństwa.

W 100% w przeglądarce

Wszystkie UUID powstają lokalnie w przeglądarce. Nic nie jest wysyłane na serwer — wygenerowane identyfikatory pozostają w pełni prywatne.

Porównanie wersji UUID

Wybór odpowiedniej wersji UUID zależy od konkretnego zastosowania.

Wersja Podstawa Sortowalne Prywatność Zastosowanie
v1 Timestamp + adres MAC Według czasu utworzenia Ujawnia adres MAC i czas Starsze systemy wymagające porządku czasowego
v4 122 bity kryptograficznie losowe Nie Pełna anonimowość Ogólne zastosowanie — najszerzej stosowana wersja
v5 Hash SHA-1 z przestrzeni nazw + nazwy Nie Deterministyczna, powtarzalna Spójne identyfikatory ze znanych danych (URL, DNS)
v7 Timestamp Unix (ms) + losowość Według czasu utworzenia Ujawnia tylko czas utworzenia Nowoczesne bazy danych — sortowalne, przyjazne indeksom (RFC 9562)

UUID a inne formaty identyfikatorów

ULID

26 znaków, Crockford Base32

Sortowalny leksykograficznie podobnie jak UUID v7, ale stosuje kodowanie Crockford Base32 (26 znaków zamiast 36). UUID v7 jest obecnie standaryzowaną przez IETF alternatywą o szerszym wsparciu narzędziowym.

nanoid

21 znaków, alfabet bezpieczny dla URL

Krótszy i bezpieczny dla URL, idealny tam, gdzie liczy się zwięzłość. Nie jest formalnym standardem — brakuje mu natywnych typów w bazach danych i bibliotek wieloplatformowych dostępnych dla UUID.

CUID2

Zmienna długość, alfanumeryczny

Zaprojektowany pod skalowanie horyzontalne z odpornością na kolizje. Mniej rozpowszechniony niż UUID; brak natywnego wsparcia w bazach danych. Dla standaryzowanych identyfikatorów sortowanych czasowo lepszym wyborem jest UUID v7.

Przykłady wersji UUID

UUID v4 (losowy)

550e8400-e29b-41d4-a716-446655440000

Najczęściej używana wersja. 122 bity kryptograficznej losowości dają ponad 5,3 × 10³⁶ możliwych wartości — wystarczająco do praktycznie każdego zastosowania, w którym wymagana jest unikalność bez koordynacji.

UUID v7 (uporządkowany czasowo)

01906b5e-4a3e-7234-8f56-b8c12d4e5678

Łączy 48-bitowy timestamp Unix w milisekundach z danymi losowymi. UUID są sortowane chronologicznie, co czyni je idealnymi jako klucze główne baz danych, gdzie liczy się lokalność indeksu. Zalecany dla nowych projektów zamiast v1 i v4.

UUID v1 (czasowy)

6ba7b810-9dad-11d1-80b4-00c04fd430c8

Koduje 60-bitowy timestamp i 48-bitowy adres MAC maszyny generującej. Gwarantuje unikalność w czasie i przestrzeni, ale może ujawniać identyfikatory sprzętu. Zastąpiony przez v6/v7 w RFC 9562.

UUID v5 (oparty na nazwie SHA-1)

886313e1-3b8a-5372-9b90-0c9aee199e5d

Deterministyczny UUID powstały przez hashowanie przestrzeni nazw DNS z nazwą „python.org” za pomocą SHA-1. Ta sama przestrzeń nazw i ta sama nazwa zawsze dają ten sam UUID, dzięki czemu v5 doskonale nadaje się do powtarzalnych identyfikatorów.

Jak używać

  1. 1

    Wybierz wersję UUID

    Należy wybrać spośród v1 (czasowy), v3 (oparty na nazwie i MD5), v4 (losowy), v5 (oparty na nazwie i SHA-1) lub v7 (losowy uporządkowany czasowo). Każda wersja ma inne przeznaczenie — v4 jest najczęściej stosowana do ogólnych zastosowań.

  2. 2

    Skonfiguruj opcje

    Dla v3 i v5 należy wybrać przestrzeń nazw (DNS, URL, OID, X.500 lub własną) i wpisać nazwę do hashowania. Następnie należy ustawić ilość od 1 do 50 oraz wybrać format wyjściowy: standardowy małymi literami, WIELKIMI LITERAMI, bez myślników lub w nawiasach klamrowych {GUID}.

  3. 3

    Wygeneruj UUID

    Wystarczy kliknąć przycisk generowania. Każdy UUID powstaje przy użyciu Web Crypto API (crypto.getRandomValues()) zapewniającego bezpieczeństwo kryptograficzne. Pola właściwe dla danej wersji, takie jak timestamp (v1/v7) czy hash (v3/v5), są kodowane poprawnie.

  4. 4

    Skopiuj i użyj

    Kliknięcie przycisku „Kopiuj” obok dowolnego UUID przenosi go do schowka, a „Kopiuj wszystko” pobiera od razu wszystkie wygenerowane identyfikatory. Zakładka dekodowania pozwala przeanalizować istniejący UUID — jego wersję, wariant, timestamp oraz pozostałe osadzone informacje.

Typowe zastosowania

Klucze główne baz danych
UUID v4 lub v7 sprawdzają się jako unikalne klucze główne bez koordynacji między węzłami bazy danych. UUID v7 jest szczególnie odpowiedni, ponieważ jego porządek czasowy poprawia wydajność indeksów B-tree.
Systemy rozproszone
Pozwala generować unikalne identyfikatory niezależnie w mikrousługach, kolejkach komunikatów oraz systemach event sourcing. UUID eliminują potrzebę istnienia centralnej usługi przydzielającej identyfikatory.
Tworzenie API
Tworzenie unikalnych identyfikatorów żądań, identyfikatorów korelacyjnych i kluczy idempotencji dla API REST i GraphQL. UUID ułatwiają śledzenie żądań przez granice rozproszonych usług.
Zarządzanie sesjami i token-ami
Generowanie unikalnych identyfikatorów sesji i tymczasowych token-ów dla przepływów uwierzytelniania. UUID dają wystarczającą unikalność, by zapobiegać kolizjom sesji nawet przy dużej liczbie użytkowników.
Testowanie i development
Szybkie generowanie danych testowych, identyfikatorów mockowych i unikalnych identyfikatorów fixtur w testach automatycznych. Generowanie wsadowe ułatwia zapełnianie deweloperskich baz danych i zestawów testowych.

Szczegóły techniczne

Struktura UUID
UUID ma 128 bitów (16 bajtów) reprezentowanych jako 32 znaki szesnastkowe w formacie 8-4-4-4-12. Bity 48–51 (13. cyfra szesnastkowa) kodują numer wersji. Bity 64–65 kodują pole wariantu, które identyfikuje układ UUID. Pozostałe bity przenoszą zawartość właściwą dla wersji: timestamp, dane losowe lub wynik hash.
Bity wersji
Bity 48–51 (wyższy półbajt 7. bajtu) kodują wersję UUID: 0001 = v1 (czasowy), 0011 = v3 (oparty na nazwie z MD5), 0100 = v4 (losowy), 0101 = v5 (oparty na nazwie z SHA-1), 0110 = v6 (przeporządkowany czasowo), 0111 = v7 (oparty na epoce Unix). Te cztery bity są zawsze ustawiane jawnie podczas generowania.
Pole wariantu
Bity 64–65 (dwa najbardziej znaczące bity 9. bajtu) definiują wariant. Wzorzec 10x oznacza UUID zgodne z RFC 4122/9562 (zdecydowana większość). Wzorzec 110 oznacza GUID-y Microsoftu z mieszaną kolejnością bajtów. Wzorzec 0xx oznacza UUID kompatybilne wstecz z NCS (legacy). Wzorzec 111 jest zarezerwowany do przyszłego użytku.
Standard RFC 9562
RFC 9562, opublikowany w maju 2024, zastępuje RFC 4122 jako definitywną specyfikację UUID. Formalnie wprowadza wersje UUID 6, 7 i 8. Wersja 6 przeporządkowuje pola v1 dla sortowalności. Wersja 7 wykorzystuje 48-bitowy timestamp Unix w milisekundach plus dane losowe, co czyni ją zalecaną wersją dla nowych UUID czasowych. Wersja 8 udostępnia format dla niestandardowych UUID specyficznych dla implementacji. RFC 9562 formalnie deprecjonuje także v1 na rzecz v6/v7.

Dobre praktyki

Wybór odpowiedniej wersji
Wersji v4 używa się do uniwersalnych unikalnych identyfikatorów, gdy nie jest potrzebny porządek ani determinizm. Wersję v7 stosuje się do kluczy głównych baz danych — jej porządek czasowy wyraźnie poprawia wydajność indeksów. Wersję v5 wybiera się, gdy potrzeba deterministycznych identyfikatorów wyprowadzanych z nazw (lepiej v5 niż v3 ze względu na silniejsze hashowanie).
UUID v7 jako klucze główne baz danych
Porządek czasowy UUID v7 utrzymuje sekwencyjność wstawień w indeksach B-tree, ograniczając fragmentację indeksu o około 90% w porównaniu z losowymi UUID v4. Przekłada się to na szybsze zapisy, mniejsze indeksy i lepsze wykorzystanie cache. Większość nowoczesnych baz danych (PostgreSQL 17+, MySQL 8.0+) ma natywne wsparcie UUID zoptymalizowane pod ten wzorzec.
UUID nie nadają się jako tokeny bezpieczeństwa
UUID są zaprojektowane do unikalności, nie do tajności. UUID v1 ujawnia timestamp generowania i adres MAC. UUID v4 ma jedynie 122 bity entropii w przewidywalnej strukturze. Do tokenów bezpieczeństwa, kluczy API czy sekretów sesji należy używać dedykowanego CSPRNG generującego 128 lub 256 bitów czysto losowych danych — bez narzutu strukturalnego UUID.
Walidacja przed parsowaniem
Format UUID należy zawsze walidować wyrażeniem regex przed parsowaniem lub zapisem. Niepoprawne dane wejściowe trzeba odrzucać już na granicach systemu — w endpoint-ach API, w obsłudze formularzy i przy zapisie do bazy. Zapobiega to atakom przez wstrzyknięcie, uszkodzeniom danych oraz trudnym do zdiagnozowania błędom wynikającym z propagacji nieprawidłowych identyfikatorów w systemie.

Najczęściej zadawane pytania

Czym jest UUID?
UUID (Universally Unique Identifier) to 128-bitowy identyfikator znormalizowany przez RFC 9562. Zapisuje się go jako 32 cyfry szesnastkowe w pięciu grupach rozdzielonych myślnikami, w formacie 8-4-4-4-12 — na przykład 550e8400-e29b-41d4-a716-446655440000. UUID są zaprojektowane tak, aby były globalnie unikalne bez konieczności rejestracji w centralnym urzędzie. Termin GUID (Globally Unique Identifier) to nazwa Microsoftu dla tej samej koncepcji i wykorzystuje identyczny format. UUID są szeroko stosowane w bazach danych, systemach rozproszonych, API oraz wszędzie tam, gdzie tworzenie oprogramowania wymaga unikalnych identyfikatorów. Przy ponad 5,3 × 10³⁶ możliwych UUID v4 prawdopodobieństwo wygenerowania duplikatu jest astronomicznie małe, co czyni je bezpiecznymi do niezależnego generowania w nieskoordynowanych systemach.
Jakie są różnice między wersjami UUID?
UUID v1 koduje 60-bitowy timestamp i 48-bitowy adres MAC maszyny, gwarantując unikalność w czasie i przestrzeni, ale potencjalnie ujawniając tożsamość sprzętu. UUID v3 hashuje przestrzeń nazw oraz nazwę algorytmem MD5, dając deterministyczny UUID — te same dane wejściowe zawsze dają ten sam wynik. UUID v4 wypełnia 122 z 128 bitów kryptograficznie bezpiecznymi danymi losowymi, dzięki czemu jest najszerzej stosowaną wersją do uniwersalnych identyfikatorów. UUID v5 jest identyczny z v3, ale używa SHA-1 zamiast MD5, oferując silniejszą odporność na kolizje hash. UUID v7, wprowadzony przez RFC 9562 (maj 2024), osadza 48-bitowy timestamp Unix w milisekundach, po którym następują bity losowe — tworząc UUID, które są jednocześnie unikalne i naturalnie sortowalne według czasu utworzenia. Wybór wersji zależy od wymagań: v4 dla prostoty, v5 dla determinizmu, v7 dla kluczy bazy danych sortowanych czasowo.
Kiedy stosować UUID v4, a kiedy v7?
UUID v4 to najpopularniejsza wersja i znakomity domyślny wybór. Generuje 122 bity czystej losowości, nie wymaga konfiguracji i działa wszędzie. Wersję v4 stosuje się wtedy, gdy wystarczy zwykły unikalny identyfikator, a porządek nie ma znaczenia. UUID v7 jest lepszym wyborem, gdy UUID mają być używane jako klucze główne baz danych lub muszą być sortowane według czasu utworzenia. Ponieważ v7 osadza w najbardziej znaczących bitach timestamp z dokładnością do milisekundy, takie UUID sortują się naturalnie w porządku chronologicznym. Ta właściwość drastycznie poprawia wydajność indeksów B-tree — wstawienia trafiają zawsze na koniec indeksu, a nie w losowe miejsca, ograniczając podziały stron i fragmentację nawet o 90%. W nowych projektach w 2026 roku ogólne zalecenie brzmi: używać v7 dla kluczy bazy danych, a v4 do reszty. Obie wersje są równie unikalne i kryptograficznie losowe w swoich częściach losowych.
Jakie jest prawdopodobieństwo kolizji UUID?
UUID v4 ma 122 bity losowe, co daje 2^122 (około 5,3 × 10³⁶) możliwych wartości. Aby uzyskać 50% prawdopodobieństwo wystąpienia choć jednej kolizji, należałoby wygenerować około 2,71 × 10¹⁸ UUID — czyli 2,71 tryliona. Dla porównania: gdyby generować miliard UUID na sekundę, osiągnięcie 50% prawdopodobieństwa kolizji zajęłoby około 86 lat. Przy bardziej realistycznych tempach generowania prawdopodobieństwo jest znikome. Na przykład wygenerowanie 10 milionów UUID daje prawdopodobieństwo kolizji rzędu 1 do 10²². W praktyce awarie sprzętu, błędy oprogramowania i pomyłki ludzkie są miliardy razy bardziej prawdopodobne niż kolizja UUID v4. Obliczenia opierają się na wzorze problemu urodzin: p(n) ≈ n² / (2 · 2^122).
Jaka jest różnica między UUID a GUID?
UUID (Universally Unique Identifier) i GUID (Globally Unique Identifier) to w istocie to samo. GUID to termin ukuty przez Microsoft i stosowany przede wszystkim w środowiskach Windows, .NET, COM i SQL Server. UUID to termin standardowy zdefiniowany w RFC 9562 (oraz wcześniejszym RFC 4122) i używany w większości pozostałych kontekstów, w tym w systemie Linux, Java, Python, PostgreSQL i tworzeniu aplikacji webowych. Oba wykorzystują identyczny 128-bitowy format wyświetlany jako 32 cyfry szesnastkowe w schemacie 8-4-4-4-12. Jedyna drobna różnica polega na tym, że narzędzia Microsoftu czasami pokazują GUID-y wielkimi literami w nawiasach klamrowych, na przykład {550E8400-E29B-41D4-A716-446655440000}, podczas gdy UUID konwencjonalnie zapisuje się małymi literami bez nawiasów. Narzędzie wspiera oba formaty poprzez selektor formatu wyjściowego — wystarczy wybrać format z nawiasami klamrowymi {GUID}, aby uzyskać wyjście w stylu Microsoftu.
Czy UUID v4 jest kryptograficznie bezpieczny?
Gdy generuje się go za pomocą crypto.getRandomValues() lub równoważnego CSPRNG (Cryptographically Secure Pseudo-Random Number Generator), UUID v4 zawiera 122 bity kryptograficznie bezpiecznych danych losowych. Narzędzie korzysta z Web Crypto API, który czerpie entropię z bezpiecznego źródła losowego systemu operacyjnego. Mimo to UUID nie powinny być używane jako tokeny bezpieczeństwa, hasła ani klucze szyfrujące. Choć 122 bity losowości czynią przewidywanie niewykonalnym, UUID mają strukturę przewidywalną — półbajt wersji (4) i bity wariantu są ustalone i publicznie znane. Do tokenów bezpieczeństwa lepiej użyć dedykowanych API, takich jak crypto.getRandomValues() z pełnymi 128 lub 256 bitami entropii, albo ustabilizowanych formatów jak JWT. UUID służą do identyfikacji, nie do zabezpieczania.
Jak walidować format UUID?
Poprawny UUID pasuje do wzorca regex: ^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$ (bez rozróżniania wielkości liter). Wzorzec wymusza format szesnastkowy 8-4-4-4-12, sprawdza, czy cyfra wersji (pozycja 15) zawiera się w przedziale od 1 do 7, oraz weryfikuje, że półbajt wariantu (pozycja 20) zaczyna się od 8, 9, a lub b (co wskazuje wariant RFC 4122/9562). W JavaScripcie walidację można wykonać tak: /^[0-9a-f]{8}-[0-9a-f]{4}-[1-7][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i.test(uuid). Większość języków programowania oferuje także wbudowane parsery UUID — na przykład konstruktor uuid.UUID() w Pythonie, UUID.fromString() w Javie czy uuid.Parse() w Go. Należy zawsze walidować UUID na granicach systemu przed zapisem lub przetwarzaniem, aby zapobiec atakom przez wstrzyknięcie i uszkodzeniu danych.
Czy UUID to dobre klucze główne bazy danych? (wydajność, bezpieczeństwo i najlepsza wersja)
Tak, UUID są bezpieczne i coraz częściej wybierane jako klucze główne baz danych, a UUID v7 jest wersją zalecaną. Najważniejsze zalety: (1) UUID można generować wszędzie — w klientach, na serwerach lub w funkcjach edge — bez okrężnej drogi do bazy danych, co umożliwia architektury offline-first i rozproszone. (2) UUID zapobiegają atakom przez enumerację, ponieważ nie są kolejnymi liczbami całkowitymi. (3) UUID upraszczają scalanie danych między systemami, bo identyfikatory nigdy się nie pokrywają. UUID v7 jest najlepszą wersją dla kluczy głównych, ponieważ jego porządek czasowy zachowuje sekwencyjność wstawień w indeksach B-tree, drastycznie ograniczając podziały stron, write amplification oraz fragmentację indeksu nawet o 90% w porównaniu z losowymi UUID v4. Kompromisy: UUID zajmują 16 bajtów wobec 4–8 bajtów liczb całkowitych, zwiększając pamięć dyskową i operacyjną dla indeksów. W MySQL/InnoDB, gdzie klucz główny jest indeksem klastrowanym, losowe UUID v4 mogą znacząco pogarszać wydajność — v7 rozwiązuje ten problem, gwarantując, że wstawienia zawsze trafiają na koniec indeksu, osiągając wydajność porównywalną z liczbami auto-increment. PostgreSQL przechowuje UUID natywnie w 16 bajtach przez typ uuid. W większości nowoczesnych aplikacji korzyści z globalnie unikalnego, bezkoordynacyjnego generowania identyfikatorów znacząco przewyższają dodatkowy koszt pamięci.
Czym jest przestrzeń nazw UUID (v3/v5)?
Przestrzeń nazw UUID to predefiniowany lub własny UUID pełniący rolę zakresu dla generowania deterministycznych UUID v3 i v5. RFC 4122 definiuje cztery standardowe przestrzenie nazw: DNS (6ba7b810-9dad-11d1-80b4-00c04fd430c8), URL (6ba7b811-9dad-11d1-80b4-00c04fd430c8), OID (6ba7b812-9dad-11d1-80b4-00c04fd430c8) oraz X.500 DN (6ba7b814-9dad-11d1-80b4-00c04fd430c8). Połączenie przestrzeni nazw UUID z ciągiem nazwy sprawia, że algorytm v3 lub v5 hashuje je razem, dając deterministyczny UUID — ta sama przestrzeń nazw i ta sama nazwa zawsze dają ten sam UUID. Bywa to przydatne, gdy potrzebne są powtarzalne identyfikatory wyprowadzane z sensownych nazw. Na przykład hashowanie przestrzeni nazw DNS z „example.com” zawsze daje ten sam UUID v5. Można też użyć dowolnego prawidłowego UUID jako własnej przestrzeni nazw dla aplikacyjnego schematu deterministycznych identyfikatorów.
Czym jest wartość nil UUID?
Nil UUID (zwany też zerowym UUID) ma postać 00000000-0000-0000-0000-000000000000 — wszystkie 128 bitów ustawione na zero. RFC 9562 w sekcji 5.9 definiuje go jako szczególny UUID, który może oznaczać brak wartości — analogicznie do null lub None w językach programowania. Nil UUID przydaje się jako wartość strażnicza, domyślna w systemach konfiguracyjnych lub zastępcza w rekordach baz danych, gdzie pole UUID nie może być puste, ale nie ma jeszcze rzeczywistej wartości. RFC 9562 definiuje także max UUID: ffffffff-ffff-ffff-ffff-ffffffffffff (wszystkie bity ustawione na jeden), który może pełnić rolę znacznika granicy. Ważne zastrzeżenia: nigdy nie należy używać nil UUID jako rzeczywistego identyfikatora — nie jest unikalny. Niektóre biblioteki UUID i bazy danych mogą odrzucać lub specjalnie traktować nil UUID, dlatego warto zadbać o spójną obsługę w całym systemie. W kontraktach API i schematach bazy danych zawsze należy udokumentować, czy nil UUID są akceptowane.
Czym jest UUID v7 i dlaczego warto go używać?
UUID v7 to najnowsza wersja UUID zdefiniowana w RFC 9562 (maj 2024). Osadza 48-bitowy timestamp Unix w milisekundach w najbardziej znaczących bitach, po którym następują kryptograficznie losowe dane. Dzięki tej konstrukcji powstają UUID, które są globalnie unikalne, sortowalne chronologicznie i bardzo wydajne jako klucze główne baz danych. W odróżnieniu od UUID v1, który również zawiera timestamp, v7 stosuje prostszy format epoki Unix i nie ujawnia adresu MAC. Porządek czasowy ogranicza fragmentację indeksu B-tree nawet o 90% w porównaniu z losowymi UUID v4, dając szybsze wstawienia, mniejsze indeksy i lepszą skuteczność cache. Dla nowych projektów rozpoczynanych w 2026 roku UUID v7 jest zalecanym wyborem wszędzie tam, gdzie potrzebny jest porządek czasowy — zwłaszcza dla kluczy głównych baz danych, logów zdarzeń i rozproszonych kolejek komunikatów.
Jak dekodować UUID?
Dekodowanie UUID polega na wyodrębnieniu informacji strukturalnych zakodowanych w jego 128 bitach. Każdy UUID zawiera pole wersji (bity 48–51) określające sposób jego wygenerowania oraz pole wariantu (bity 64–65) identyfikujące standard, do którego się stosuje. Poza tymi wspólnymi polami różne wersje osadzają różne dane: UUID v1 i v6 zawierają 60-bitowy timestamp i 48-bitowy węzeł (adres MAC); UUID v7 zawiera 48-bitowy timestamp Unix w milisekundach; UUID v3 i v5 zawierają obcięty hash przestrzeni nazw i nazwy. Aby zdekodować UUID, należy wkleić go do zakładki dekodowania w narzędziu. Wyświetli ono natychmiast wersję, wariant, timestamp (dla wersji czasowych) oraz status walidacji. Programowo UUID dekoduje się, parsując cyfry szesnastkowe i stosując operacje bitowe do wyodrębnienia każdego pola zgodnie ze specyfikacją RFC 9562.
UUID a ULID a nanoid — co wybrać?
UUID, ULID i nanoid służą tym samym celom — generowaniu unikalnych identyfikatorów — różnią się jednak formatem, sortowalnością i poziomem standaryzacji. UUID to najszerzej przyjęty standard (RFC 9562), wspierany natywnie przez praktycznie wszystkie bazy danych, języki i frameworki. UUID v7 zapewnia sortowanie czasowe w standardowym 128-bitowym, 36-znakowym formacie. ULID (Universally Unique Lexicographically Sortable Identifier) wyprzedza UUID v7 i wykorzystuje kodowanie Crockford Base32, dając 26-znakowy sortowalny ciąg. Odkąd UUID v7 istnieje jako standard IETF, główna przewaga ULID — sortowalność — jest dostępna w uniwersalnym formacie UUID. nanoid generuje krótsze identyfikatory (domyślnie 21 znaków) z alfabetu bezpiecznego dla URL, co jest idealne, gdy liczy się długość ciągu i nie potrzeba interoperacyjności między systemami. W większości zastosowań UUID v4 (ogólne zastosowanie) lub UUID v7 (klucze bazy danych) jest zalecanym wyborem dzięki uniwersalnemu wsparciu narzędziowemu, natywnym typom w bazach danych i formalnej standaryzacji.
Buduję mikrousługę i muszę wybrać między UUID v4 a v7 jako kluczem głównym w PostgreSQL — co wybrać i dlaczego?
Do kluczy głównych w PostgreSQL warto używać UUID v7. UUID v7 osadza w najbardziej znaczących bitach timestamp Unix z dokładnością do milisekundy, dzięki czemu generowane identyfikatory są naturalnie sortowane chronologicznie. Utrzymuje to sekwencyjność indeksów B-tree — wstawienia trafiają zawsze na koniec, a nie w losowe miejsca, co ogranicza podziały stron i fragmentację indeksu nawet o 90% w porównaniu z losowymi UUID v4. PostgreSQL 17+ ma natywny typ uuid zoptymalizowany pod ten wzorzec. UUID v4 nadal sprawdza się dla nieindeksowanych identyfikatorów, takich jak identyfikatory korelacyjne czy sesyjne tokeny, gdzie kolejność sortowania nie ma znaczenia.
Mój zespół zastanawia się, czy używać UUID, czy liczb auto-increment jako identyfikatorów bazy danych — jakie są realne kompromisy?
Liczby auto-increment są mniejsze (4–8 bajtów wobec 16 bajtów), szybsze w porównaniach i tworzą naturalnie sekwencyjne indeksy. Wymagają jednak scentralizowanej sekwencji (bazy danych), co utrudnia ich stosowanie w systemach rozproszonych, aplikacjach offline-first oraz przy migracjach danych. UUID można generować wszędzie — w klientach, funkcjach edge, w wielu bazach danych — bez koordynacji. Zapobiegają też atakom przez enumerację (użytkownicy nie zgadną /users/124, by znaleźć inne rekordy). Narzut pamięciowy jest realny, ale zwykle akceptowalny: indeks UUID ma mniej więcej dwukrotnie większy rozmiar niż indeks liczbowy. W większości nowoczesnych aplikacji UUID v7 łączy zalety obu podejść — globalna unikalność, brak koordynacji oraz porządek sekwencyjny zbliżony do auto-increment.

Powiązane narzędzia

Zobacz wszystkie narzędzia →