Question : Using GUIDs as primary key in Mysql innodb and how it affects inner joins

I am researching into using a GUID column as the primary key to all tables in my mysql database schema. My database is sufficiently sizable with some 150 odd tables and many tables having almost 500k + rows. The engine is primarily innodb since the data is primarily transactional with 100 thousands of insertions and updations happening in a day.

My question is that if we use guids (i.e. UUID) as primary key in such a system then:

a. will it effect the database performance in any ways (insert/delete/edit)? my research shows that if the indexes are correctly put, there should not be a problem in using the uuid as PK (as compared to auto_increment int values)

b. most importantly, i need to understand the effect on such a system when we need to run inner join queries (which are aplenty). reason for my skepticism is that if we run inner joins between, say an employee table and employee address table with employee_address_id (as a guid) as the matching column, will it not be a huge operation as compared to the case when the same ids were ints. What is the way of handling this problem (indexing or other ways) in such a case when guids (and not ints) are used.

Thanks in advance.

Answer : Using GUIDs as primary key in Mysql innodb and how it affects inner joins

PK (and any index) works faster the fewer number of bits that have to be compared. If you have to find one element in a list, it takes O(log n) time, which is usually fast. The complexity of the search does not change depending on the length of the key. Practically speaking, fetching the key can take as long as comparing the keys.

Soo....

If an int is usually 11 or 12 bytes, and a guid is 16 bytes, the difference should be trivial. If your guid is longer, the difference is probably still trivial until you get to a 100-byte guid.