I’m planning on using client provided UUID’s as the primary key in several tables in a MySQL Database.
I’ve come across various mechanisms for storing UUID’s in a MySQL database but nothing that compares them against each other. These include storage as:
- BINARY(16)
- CHAR(16)
- CHAR(36)
- VARCHAR(36)
- 2 x BIGINT
Are there any better options, how do the options compare against each other in terms of:
- storage size?
- query overhead? (index issues, joins etc.)
- ease of inserting and updating values from client code? (typically Java via JPA)
Are there any differences based on which version of MySQL your running, or the storage engine? We’re currently running 5.1 and were planning on using InnoDB. I’d welcome any comments based on practical experience of trying to use UUIDs. Thanks.
I have used UUIDs for smart client online/offline storage and data synchronization and for databases that I knew would have to be merged at some point. I have always used char(36) or char(32)(no dashes). You get a slight performance gain over varchar and almost all databases support char. I have never tried binary or bigint. One thing to be aware of, is that char will pad with spaces if you do not use 36 or 32 characters. Point being, don’t write a unit test that sets the ID of an object to “test” and then try to find it in the database. 😉