UUID（Universally Unique IDentifier 通用唯一標(biāo)識符），是一種常用的唯一標(biāo)識符，在MySQL中，可以利用函數(shù)uuid()來生產(chǎn)UUID。因為UUID可以唯一標(biāo)識記錄，因此有些場景可能會用來作為表的主鍵，但直接用UUID來作為主鍵可能存在性能缺陷，我們需要采取一些優(yōu)化手段。

目錄

一、UUID主鍵的缺陷

二、優(yōu)化方案

---

一、UUID主鍵的缺陷

在MySQL中，innodb是按照表的聚簇索引（主鍵）來組織數(shù)據(jù)存儲的，也就是主鍵的順序決定了數(shù)據(jù)存儲的順序。這也是為什么我們通常推薦用整型，自增的數(shù)字來作為表的主鍵，當(dāng)新數(shù)據(jù)插入時，主鍵一定是最大的，只要放在葉子層中最后的數(shù)據(jù)頁即可，對已有的數(shù)據(jù)不會有影響。

而如果用UUID來做主鍵，則會有2個缺陷：

• UUID的值是隨機(jī)的，因此新插入的數(shù)據(jù)有可能會插到已有數(shù)據(jù)的中間，這會導(dǎo)致整個索引樹的重新平衡和節(jié)點(diǎn)分裂，降低插入性能，數(shù)據(jù)量越大越嚴(yán)重。
• UUID是字符型，相對數(shù)字占用的存儲空間很大，這意味著主鍵很大，而主鍵又會附加到所有的二級索引中，因此所有的索引都很臃腫，消耗額外的磁盤和內(nèi)存資源，降低查詢性能。

UUID的生成方式有很多版本，這里舉2個最常用的：

• UUID V1: 通過時間戳和MAC地址來生成，可以生成順序的UUID。
• UUID V4: 通過隨機(jī)數(shù)來生成，無法生成順序的UUID。

MySQL自帶的函數(shù)uuid()是通過UUIDv1生成，因此上面第一個缺陷通常不存在，你需要注意的是某些應(yīng)用是否會自己生成非順序的UUID插入表中。

下面通過示例來看差別，我們創(chuàng)建兩張結(jié)構(gòu)一樣的表，一張用數(shù)字作為主鍵，一張用UUID作為主鍵：

create table digital_pk(
id int auto_increment primary key,
serial int);create table uuid_pk(
id varchar(36) default(uuid()) primary key,
serial int);

我們分別向2張表中插入5條數(shù)據(jù)：

insert into digital_pk(serial) values(1);
insert into digital_pk(serial) values(2);
insert into digital_pk(serial) values(3);
insert into digital_pk(serial) values(4);
insert into digital_pk(serial) values(5);

insert into uuid_pk(serial) values(1);
insert into uuid_pk(serial) values(2);
insert into uuid_pk(serial) values(3);
insert into uuid_pk(serial) values(4);
insert into uuid_pk(serial) values(5);

我們通過explain來查看索引的信息：

• explain select * from digital_pk where id=1\G

explain select * from uuid_pk where id='71b49d70-7f98-11ee-a9a1-0050569c9844'\G

可以看到uuid作為主鍵的長度是146，而數(shù)字做主鍵的長度為4，這意味著當(dāng)數(shù)據(jù)量非常大的時候，UUID的索引會非常臃腫，查詢性能會很低。

二、優(yōu)化方案

雖然通常不推薦使用UUID作為表的主鍵，但某些場景如果我們必須要用UUID作為主鍵，我們也可以通過一些方法來規(guī)避上述缺陷。

MySQL為了優(yōu)化UUID的存儲，專門提供了兩個函數(shù)：

• uuid_to_bin(uuid, swap_flag)，將字符型UUID轉(zhuǎn)換為二進(jìn)制UUID，轉(zhuǎn)換后返回的數(shù)據(jù)類型是varbinary。
• bin_to_uuid(uuid, swap_flag)，將二進(jìn)制UUID轉(zhuǎn)換為字符型UUID

在存儲的時候用uuid_to_bin(uuid, swap_flag)將UUID由字符型轉(zhuǎn)化為二進(jìn)制，可以大大縮小索引的長度，函數(shù)中的swap_flag有2個取值：

• 0 代表轉(zhuǎn)換后的數(shù)據(jù)依然是和UUID字符排序相同
• 1 代表轉(zhuǎn)換后將UUID中的time-low和time-high部分（第一和第三組）交換位置，轉(zhuǎn)換后數(shù)據(jù)可以按時間連續(xù)遞增，對InnoDB的聚簇索引還會有性能提升。注意這個僅對UUID V1版本基于時間戳生成的UUID才有效，如果是其他類型的UUID，不會得到性能提升。

下面我們利用這個函數(shù)新建一個表uuid_pk_v2:

create table uuid_pk_v2(
id binary(16) default(uuid_to_bin(uuid(),1)) primary key,
serial int);

• 這里id列的數(shù)據(jù)類型變成了binary(16)，同時uuid在存儲時轉(zhuǎn)換為二進(jìn)制型存儲。

插入1條數(shù)據(jù)

• insert into uuid_pk_v2(serial) values(1);

select id, serial from uuid_pk_v2;
select bin_to_uuid(id,1), serial from uuid_pk_v2;

• 直接查詢是以16進(jìn)制顯示的數(shù)據(jù)，這對我們沒有意義，我們需要用bin_to_uuid()函數(shù)將數(shù)據(jù)還原為字符串型UUID。

我們再看一下索引：

explain select * from uuid_pk_v2 where id=uuid_to_bin('a292725f-7fa1-11ee-a9a1-0050569c9844',1)\G

• 索引的長度從164縮短為16，只有原來的十分之一，這代表索引在磁盤和內(nèi)存占用的空間也會縮小至十分之一，掃描速度會快的多。
• 因此，雖然在插入和查詢的時候多了一層函數(shù)的處理，但是這可以完美解決前面UUID的兩個缺陷，帶來的性能提升是完全值得的。