UUID Generator
Generate unique UUID v1 and v4 identifiers
3cb5d38b-09e4-443c-ae33-4a99c3a59ac26f0a3b43-c1ae-4586-b27b-4874043dc7d074bbf886-b32e-421e-a12b-6896b6aca48e3480717b-2912-456b-8cfd-c48153da9faee44032c8-de62-4f64-bee8-67e822bf7715Generador de UUID Online - Version 4, Version 1 y ULID
¿Qué es un UUID y para qué se utiliza en programación?
UUID (Universally Unique Identifier) es un identificador estándar de 128 bits (representado como 32 dígitos hexadecimales en formato 8-4-4-4-12) diseñado para ser globalmente único sin necesidad de coordinación central ni base de datos de registro. Los UUIDs se utilizan extensivamente como: claves primarias en bases de datos distribuidas y microservicios, identificadores de sesión de usuario, tokens de transacciones financieras, nombres de archivo únicos en sistemas de almacenamiento cloud, IDs de recursos en APIs REST, identificadores de dispositivos IoT, y en cualquier sistema donde se necesiten identificadores que no colisionen entre diferentes sistemas, servidores o bases de datos independientes.
¿Cuáles son las versiones de UUID y sus diferencias?
Existen varias versiones de UUID con características distintas: UUID v1 combina timestamp de 60 bits, dirección MAC del equipo y un contador, garantizando unicidad temporal pero revelando información del sistema (cuándo y dónde se generó). UUID v4 es completamente aleatorio (122 bits de entropía), siendo la versión más utilizada por su simplicidad y privacidad. UUID v5 genera identificadores determinísticos basados en un namespace y nombre usando SHA-1, útil cuando necesitas el mismo UUID para la misma entrada. UUID v7 (RFC 9562, 2024) es la nueva recomendación que combina timestamp Unix ordenable en milisegundos con aleatoriedad, ideal para bases de datos donde el orden de inserción importa para rendimiento de índices.
¿Cómo afectan los UUIDs al rendimiento de bases de datos?
Usar UUID aleatorios (v4) como clave primaria tiene implicaciones de rendimiento importantes: los índices B-tree sufren con inserciones aleatorias causando page splits y fragmentación, el tamaño de 36 caracteres (o 16 bytes binario) consume más espacio que auto-increment integers. Para mitigar estos problemas: UUID v7 o ULID (Universally Unique Lexicographically Sortable Identifier) ofrecen ordenación temporal natural. PostgreSQL tiene tipo UUID nativo optimizado. En MySQL, considera almacenar UUIDs como BINARY(16) en lugar de CHAR(36), o usar la función UUID_TO_BIN() con swap_flag para mejor ordenación. Evalúa si realmente necesitas UUIDs o si IDs secuenciales son suficientes para tu caso de uso.
Preguntas frecuentes
¿Pueden colisionar dos UUIDs generados aleatoriamente (v4)?
Teóricamente sí es posible una colisión, pero la probabilidad es astronómicamente baja. Con UUID v4 y sus 122 bits de aleatoriedad, necesitarías generar aproximadamente 2.71 × 10^18 (2.71 trillones) de UUIDs para tener apenas un 50% de probabilidad de encontrar una colisión (paradoja del cumpleaños). En la práctica, esto significa que para cualquier aplicación real, las colisiones son efectivamente imposibles. Generando un millón de UUIDs por segundo, tardarías 85 años en tener una probabilidad del 0.000001% de colisión.
¿Cuál es la diferencia entre UUID y GUID?
Son esencialmente lo mismo con diferente terminología. GUID (Globally Unique Identifier) es el término utilizado por Microsoft en Windows y tecnologías .NET, mientras que UUID es el término del estándar internacional RFC 4122 usado en el resto de la industria. La estructura de 128 bits, el formato de representación (8-4-4-4-12), y el propósito son idénticos. Puedes usar los términos indistintamente, aunque UUID es técnicamente el nombre oficial del estándar.
¿Puedo usar UUID como token de seguridad o API key?
UUID v4 tiene 122 bits de entropía criptográfica, lo cual es adecuado para tokens de seguridad media como enlaces de reset de password de un solo uso o tokens de verificación de email. Sin embargo, para API keys de larga duración, tokens de autenticación críticos, o claves de sesión, es recomendable usar generadores criptográficos específicos que produzcan tokens más largos (256+ bits). También considera usar JWTs firmados para tokens que necesiten transportar claims verificables, o tokens opacos almacenados en base de datos con hash.