UUID v4 vs v7: vilken unik identifierare ska du välja?
En UUID är en 128-bitars unik identifierare utan central samordning. Version 4, helt slumpmässig, har dominerat i åratal. Version 7, nyare (RFC 9562, 2024), inkluderar en tidsstämpel i början för att producera tidsordnade identifierare. Denna skillnad, till synes obetydlig, förändrar databasprestandan radikalt. Så här väljer du.
Vad är en UUID?
En UUID (Universally Unique Identifier) är ett 128-bitars tal som representeras av 32 hexadecimala tecken grupperade i fem block, till exempel 550e8400-e29b-41d4-a716-446655440000. Dess existensberättigande: att generera en unik identifierare utan att be en central auktoritet, vilket gör den idealisk för distribuerade system. Du kan generera dem med vår UUID-generator.
Det finns flera versioner; de mest relevanta idag för postnycklar är v4 (slumpmässig) och v7 (tidsordnad).
UUID v4 (slumpmässig)
UUID v4 består av 122 slumpmässiga bitar (resten kodar version och variant). Sannolikheten för kollision är så låg att den är försumbar i praktiken. Det är standardversionen i de flesta språk och bibliotek.
- Oförutsägbar: perfekt för tokens eller publika identifierare som man inte vill ska kunna gissas
- Inget informationsläckage: avslöjar varken datum eller skapelseordning
- Nackdel: helt oordnad, vilket sliter på databasindex
UUID v7 (tidsordnad)
UUID v7 placerar en Unix-tidsstämpel i millisekunder på sina första 48 bitar, följt av slumpmässiga bitar. Två UUID v7 som genereras vid olika tidpunkter sorteras därför i den ordning de skapades, samtidigt som de förblir unika och praktiskt taget omöjliga att gissa.
- Sorterbar: den lexikografiska ordningen motsvarar den kronologiska ordningen
- Indexvänlig: infogningar sker i slutet av indexet, som ett auto-inkrement
- Motvikt: den avslöjar skapelseögonblicket, vilket kan vara oönskat för en publik identifierare
Jämförelsetabell
| Kriterium | UUID v4 | UUID v7 |
|---|---|---|
| Sammansättning | 122 slumpmässiga bitar | Tidsstämpel + slumpmässigt |
| Tidsordnad | Nej | Ja |
| Sorterbar | Nej | Ja (kronologiskt) |
| Indexprestanda | Låg (fragmentering) | Hög (sekventiella infogningar) |
| Oförutsägbarhet | Total | Hög men avslöjar ögonblicket |
| Informationsläckage | Inget | Skapelsedatum |
| Mognad / stöd | Universell | Ny (RFC 9562, 2024) |
Påverkan på databaser
Detta är kärnan i ämnet. Relationsdatabaser lagrar sina index i B-träd (B-tree). Att infoga slumpmässiga nycklar (v4) sprider skrivningarna överallt i indexet, vilket orsakar fragmentering, siduppdelningar och en mindre effektiv cache. Vid stora volymer försämras infogningsprestandan tydligt.
Ordnade nycklar (v7) infogas alltid i slutet av indexet, som en auto-inkrementerad identifierare. Man får snabba infogningar, bättre lokalitet och ett kompaktare index. Detta är särskilt tydligt med en primärnyckel i InnoDB (MySQL), där primärnyckeln bestämmer radernas fysiska ordning.
När du ska välja den ena eller andra
Välj UUID v4 när
- Identifieraren är publikt exponerad och inte får avslöja något
- Du genererar tokens, delningslänkar, hemligheter
- Ordning och skapelsedatum inte får kunna gissas
- Du vill ha maximal kompatibilitet med det befintliga
Välj UUID v7 när
- UUID:n fungerar som primärnyckel i en databas
- Infogningsvolymen är hög och indexprestandan räknas
- Du vill sortera efter skapelseordning utan en dedikerad kolumn
- Att avslöja skapelseögonblicket inte är ett problem
Rekommendation
För en primärnyckel i en databas, föredra hädanefter UUID v7: du behåller UUID:ns distribuerade unikhet samtidigt som du undviker v4:s indexstraff. Behåll UUID v4 för publika identifierare, tokens och hemligheter, där total oförutsägbarhet och frånvaro av tidsläckage väger tyngst.
Kontrollera ändå stödet för v7 i ditt språk och din ORM: RFC:n är ny, men antagandet går snabbt framåt.
Vanliga frågor
Är UUID v7 mindre säker än v4?
Den förblir mycket svår att gissa tack vare sina slumpmässiga bitar, men den avslöjar skapelseögonblicket via sin tidsstämpel. För en publik identifierare där datumet inte får läcka, eller en hemlighet, föredra v4.
Varför saktar UUID v4 ner databaser?
Därför att dess slumpmässiga värden sprider infogningarna över hela B-tree-indexet, vilket fragmenterar sidorna och minskar cachens effektivitet. Den ordnade v7 infogar i slutet av indexet och undviker detta problem.
Kan jag migrera från v4 till v7?
Ja, för nya poster: de två formaten samexisterar i samma UUID-kolumn. Det är inte nödvändigt att skriva om historiken; växla bara genereringen av nya nycklar till v7.
Vad gäller versionerna v1 och v6?
v1 kodar tidsstämpeln och MAC-adressen, vilket medför integritetsproblem. v6 omordnar v1 för att göra den sorterbar. För ett nytt projekt är v7 den ordnade version som rekommenderas av RFC 9562.