Inserting performance for UUID primary_key index

Question

I have read that the insert performance for UUID as a primary_key depends on how many records exists in the database. With the greater number of records the more time it taking to insert records

https://kccoder.com/mysql/uuid-vs-int-insert-performance/

The author for the above article has run experiments, he thinks its because there are greater number of reads for UUID primary_key insert than other auto incremented integers.

I wanted to ask whether databases automatically create an index for the the chosen primary_key If the UUID primary_key index is the problem, would the insert problem be solved by using an integer as the primary_key index while still keeping the UUID field, then switching the primary keys to UUID, the problem then is would the foreign key references to integer ID propagate to the UUID field upon the switching?

Answer 1

whether databases automatically create an index for the the chosen primary_key

Yes. Primary keys are always indexed. In some databases, the index is a clustered index (meaning that the data on the data pages is actually sorted by the key). In other databases, the index is to enforce the uniqueness constraint.

The issue with UUIDs and indexes is that new values are not necessarily larger than older values. That means that an insert is typically going "between" two existing records. When this happens you have fragmentation -- that is, existing data pages need to make room for new records and sometimes even split into two pages.

An auto-incremented integer does not have this problem. It to is indexed (and clustered in MySQL). However, the newer values are bigger than any existing value -- the definition of auto-incrementing. So, new values go at the end. Fragmentation is only an issue when rows are deleted or if you manually set the value.

I would recommend that you use auto-incremented primary keys unless you have a specific reason for UUIDs.