CREATE TABLE `cust` (
`Cust_Id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`Server_Id` smallint(6) NOT NULL DEFAULT ’1′,
`First_Name` char(15) DEFAULT NULL,
`Last_Name` char(20) DEFAULT NULL,
PRIMARY KEY (`Cust_Id`,`Server_Id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=latin1

When each database is defined, run an app that alters the default value of the Server_Id of each table. (You probably also want a ServerId table with a row set to the same value). When the table data gets merged from other servers, you still have unique rows and you know which server created the row. The user app would identify each row as ccccc.sss where ccccc is the Cust_Id and sss is the server id. So the user sees customer id of 1234.21 and the program behind the scene just splits it into Cust_Id=1234 and Server_Id=21.

It is fast and it is readable. Of course it all depends on the administrator setting up unique Server_Id values for each server but if they are on a network you can write an app to do it and verify it.

Mike

First simply SELECT REVERSE(UNHEX(REPLACE(UUID(),’-',”))); this will give us the UNHEXed and REVERSEd UUID in the way that Jens Wagner above suggests. Then you can place this value into your database as you please.

Then when you retrieve the UUID from the database later, you call SELECT HEX(REVERSE(‘{$uuid}’)); And to make the UUID look more “natural,” simply run strtolower() to remove the caps.

1388681F-7348-11DF-83CD-D0B6181E9833
13CF3551-7348-11DF-8556-D1B6181E9833
13F8B66F-7348-11DF-BBC6-D2B6181E9833
141E8E03-7348-11DF-BFCE-D3B6181E9833
1438CCD7-7348-11DF-807F-D4B6181E9833

To improve InnoDB insert performance, primary keys should be inserted with least changing bits first, correct?

I wrote two functions to encode and decode UUIDs, please find them below.

Best,
-jens

DELIMITER $$

CREATE FUNCTION ENCODE_UUID (uuid CHAR(36))
RETURNS BINARY(16)
DETERMINISTIC
BEGIN
RETURN REVERSE(UNHEX(REPLACE(uuid, ‘-’,”)));
END
$$

DELIMITER $$

CREATE FUNCTION DECODE_UUID (uuid BINARY(16))
RETURNS CHAR(36)
DETERMINISTIC
BEGIN
RETURN concat(
HEX(LEFT(REVERSE(uuid),4)),’-',
HEX(MID(REVERSE(uuid),5,2)),’-',
HEX(MID(REVERSE(uuid),7,2)),’-',
HEX(MID(REVERSE(uuid),9,2)),’-',
HEX(RIGHT(REVERSE(uuid),6))
);
END
$$

SELECT DECODE_UUID(ENCODE_UUID(’0935C9C3-7345-11DF-BADD-A8B4181E9833′))

BTW in PHP that looks like this:
$uuid = substr($uuid, 0, . substr($uuid, 9, 4) . substr($uuid, 14, 4) . substr($uuid, 19, 4);
where $uuid is the result of doing a SELECT UUID() in MySQL.

1. Concatenate the numeric user id (1-9 digits) and the UNIX timestamp (10 digits)
–> [i.e. "3333" . "1111111111" = "33331111111111"] ***GUARANTEED UNIQUE.

2. Convert to base-36
–> [ "33331111111111" --> "a3gsei3"] — (if I had 100 million users, the longest ID would still only be 10 characters)

3. Store as binary in CHAR().

My best guess is that this strategy is a win-win (for my situation) over GUIDs and INTs. I have guaranteed-unique ids (since they are tied to the user id and the timestamp) that are available without querying the database. PLUS, they are SIGNIFICANTLY shorter than GUIDs (they are 1/3 the size).

Admittedly, I’m relatively new to highly-scalable database architecture, so I’d appreciate any thoughts or feedback. Thanks.

I would also like to see a UUID data type (which would use 16-byte binary representation instead of VARCHAR(36))