views:

3056

answers:

2

This is the best way I could come up with to convert a MySQL GUID/UUID generated by UUID() to a binary(16):

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

And then storing it in a BINARY(16)

Are there any implications of doing it this way that I should know of?

+2  A: 

Not much implications. It will slow down the queries a little, but you will hardly notice it.

UNIQUEIDENTIFIER is stored as 16-byte binary internally anyway.

If you are going to load the binary into a client and parse it there, note the bit order, it may have other string representation than the initial NEWID().

Oracle's SYS_GUID() function is prone to this issue, converting it to a string gives different results on client and on server.

Quassnoi
A: 

I would hash it into a 8-byte integer and store the integer using a low-collision high-efficiency one-way hash algorithm like MurmurHash64A. This uses a lot less space and can be indexed and/or partitioned on. There is a SourceForge project that includes MemCached functions for mySQL (http://forge.mysql.com/projects/project.php?id=250) which might include MurmurHash64A, since Memchached uses it, but I don't know. Or look at this implementation of FNV for mySQL: http://www.xaprb.com/blog/2008/03/09/a-very-fast-fnv-hash-function-for-mysql/

bretlowery