What is a good primary key for MySQL

When designing a relational table structure , Designing a primary key is an essential step .

Practical application , It is common to see that some tables use continuous autoincrement id A primary key , Some tables use uuid A primary key , Snowflakes are also used id Primary key .

For in mysql When designing tables in Chinese ,mysql It is officially recommended not to use uuid Or a snowflake that doesn't continue and doesn't repeat id (long Shape and uniqueness , Single machine increment ), It is recommended to increase the primary key continuously id, The official recommendation is auto_increment, So why not recommend uuid, Use uuid What's the harm ？

First, compare the data volume ：

towards mysql Insert 100 ten thousand Data , Use uuid As a primary key, it is very inefficient , Use snow id The efficiency of , Use Self increasing id It's the most efficient . Use uuid The way to , In case of large amount of data , Efficiency will plummet .

Use uuid and Self increasing id Index structure comparison of

1、 Self increasing id The internal structure of

The values of the self increasing primary key are sequential , therefore Innodb Store each record at the end of a record . When the maximum fill factor of the page is reached (innodb The default maximum fill factor is page size 15/16, Will be set aside 1/16 Space for future changes )：

a、 The next record will be written to the new page , Once the data is loaded in this order , It's going to fill the pages in almost the order of the primary keys , Improved the maximum fill rate of the page , There will be no waste of pages ;

b、 The newly inserted row must be next to the original maximum data row ,mysql Location and addressing are fast , There is no additional cost to calculate the position of the new row ;

c、 Reduced page fragmentation and fragmentation .

2、uuid The internal structure of

because uuid Self increasing of relative order id There are no rules to be said for , The value of the new row does not have to be larger than the value of the previous primary key , therefore innodb You can't always insert new rows at the end of the index , It's about finding new locations for new lines to allocate new space .

This process requires a lot of extra work , Data out of order can lead to data scattered , Will lead to the following problems ：

a、 The target page written is likely to have been flushed to disk and removed from the cache , Or it hasn't been loaded into the cache yet ,innodb Before inserting, you have to find and read the target page from disk into memory , This will lead to a lot of randomness IO;

b、 Because the writing is out of order ,innodb Have to do frequent page splitting operations , To allocate space for new rows , Page splitting causes a lot of data to be moved , At least three pages need to be modified at a time ;

c、 Due to frequent page splits , The page becomes sparse and filled irregularly , Eventually, the data will be fragmented .

We're putting random values （uuid and snow id） Load to cluster index (innodb The default index type ) in the future , Sometimes it needs to be done once OPTIMEIZE TABLE To rebuild tables and optimize page filling , It will take time again .

Use Self increasing id The shortcomings of ：

a、 When a crawler crawls a database , According to the database self increment id Get business growth information , It's easy to analyze your business ;

b、 For high concurrency loads ,innodb When inserting by primary key, there will be obvious lock contention , The upper bound of the primary key will become a hot topic of contention , Because all the insertions happen here , Concurrent inserts can lead to gap lock contention ;

c、Auto_Increment The lock mechanism will cause the preemption of self increasing lock , There is a certain loss of performance .