Selection of Primary Key for distributed databases

Question

I am implementing an application in which there will be a database in Oracle 11G and multiple other MySQL databases. All databases will be synchronized with each other at least after 30 mins. Initially i thought of implementing GUID/UUID as primary key but then i came across its cons in innodb and got little worried.
I just want that my primary key to be unique with good performance which means that i am certainly looking for indexing. Please suggest what should i keep as my primary key. It is pertinent to mention that my database MySQL will be running on simple intel corei3 and i expect to have a million records on it; whereas, oracle will run on a server which is not an issue.

Answer 1

UUID/GUID has the problem of being "random". This leads to difficulty in caching data. The "next" UUID could be anywhere in the table/index. If the entire data (or index) is not small enough to fit in cache, then it will probably incur a disk hit.

If you need to generate ids in multiple servers, perhaps the best way is to have a two-part id. The first part is a small number representing the source of the id, and the second part is some form of sequence.

That could be implemented either as two fields: PRIMARY KEY (machine, seq) or as the combination of the values in a single number. Example: Machine 1 has ids starting with 1000000000; machine 2 has ids starting with 2000000000; etc. (You would, of course, have to carefully design the numbers to avoid running out of space for either part.)

INSERTs would be hitting one "hot spot" per machine. If the SELECTs tend to fetch "recent" rows, then they would also be hitting hot spots, not the entire table.

In MySQL, the compound PK could be:

seq ... AUTO_INCREMENT,
machine TINYINT UNSIGNED NOT NULL,
PRIMARY KEY(machine, seq),
INDEX(seq)

Yes, that is sufficient to make the auto_increment work.

In MySQL, the single-column PK would require some form of sequence simulation.