2009-02-13 81 views
29

Ésta es la mejor manera de que pudiera llegar a convertir una MySQL GUID/UUID generado por UUID() a un binario (16):El almacenamiento de MySQL GUID/UUID

UNHEX(REPLACE(UUID(),'-','')) 

Y luego almacenarla en una BINARIO (16)

¿existen implicaciones de hacerlo de esta manera que debería saber de?

+0

Sí, claro, pero podría obtener mejoras de rendimiento marginales si dependiera de la generación de guid de la aplicación y de la eliminación y el revenido (en mi caso, .NET) – nawfal

+0

@nawfal, mayo ser una respuesta oblicua a OP, pero realmente me gustaría ver su comentario lleno de ejemplos. –

Respuesta

8

No muchas implicaciones. Disminuirá un poco las consultas, pero apenas lo notarás.

UNIQUEIDENTIFIER se almacena como 16-byte binary internamente de todos modos.

Si va a cargar el binario en un cliente y analizarlo allí, tenga en cuenta bit order, puede tener otra representación de cadena que la inicial NEWID().

OracleSYS_GUID() La función es propensa a este problema, convirtiéndola en una cadena da diferentes resultados en el cliente y en el servidor.

+0

Agregaría al comentario algún material que desenterré. Las consideraciones sobre UUID en MySQL deberían pensar en el rendimiento y en la singularidad. Mientras que era un poco más viejo, una prueba de rendimiento interesante estaba aquí: http://kccoder.com/mysql/uuid-vs-int-insert-performance/ - Esto muestra un punto de sensibilidad alrededor de MySQL y asegura los valores "ÚNICOS" en MySQL. Estoy seguro de que ha habido mejoras, pero el tamaño del campo, la estructura del índice contenido, etc. deben contemplarse si tiene la oportunidad. BINARY (16)/CHAR (16) parece ser el camino a seguir. –

+0

Investigando un poco más a fondo también encontré un buen enlace sobre "manejo de índices BINARY". Aquí está el enlace: http://mysqlserverteam.com/storing-uuid-values-in-mysql-tables/ - Animo a cualquiera que esté buscando una conversión a MySQL a que revise este blog también. Se plantean algunos puntos importantes para considerar cómo almacenar de manera óptima la ID BINARY. Su caso de uso puede variar en función de cómo implemente el UUID, pero tiene puntos importantes para ordenar bits y usar columnas calculadas para cualquier necesidad de 'lectura humana'. –

+0

Estoy confundido por qué esto es aceptado, cuando la terminología y las suposiciones de la respuesta parecen ser exclusivas de MS SQL, no de MySQL. –

-4

Lo convertiría en un entero de 8 bytes y almacenaría el número entero usando un algoritmo de hash de una vía de baja eficiencia y alta eficacia de colisión como MurmurHash64A. Esto usa mucho menos espacio y puede ser indexado y/o particionado. Hay un proyecto de SourceForge que incluye funciones MemCached para mySQL (http://forge.mysql.com/projects/project.php?id=250) que puede incluir MurmurHash64A, ya que Memchached lo usa, pero no sé. O mire esta implementación de FNV para mySQL: http://www.xaprb.com/blog/2008/03/09/a-very-fast-fnv-hash-function-for-mysql/

+9

No. Un UUID tiene 128 bits. Si destruye el UUID de 128 bits y pierde la mitad de sus bits (8 bytes = 64 bits), entonces no tiene sentido usar un UUID. El objetivo de usar UUID es tener una EXTREMADAMENTE baja probabilidad de duplicados generados. Si hace un número de 8 bits arrojando una moneda por cada bit, hay 256 valores posibles. Un número de 4 bits solo tiene 16. Es muy probable que tengas duplicados en 64 bits; utiliza google para descubrir la probabilidad. –

Cuestiones relacionadas