別亂用UUID了，自增ID和UUID性能差距你測(cè)試過(guò)嗎？

• 一、準(zhǔn)備表&數(shù)據(jù)
• 二、500w級(jí)數(shù)據(jù)測(cè)試
• 2.1 錄入500W數(shù)據(jù)，自增ID節(jié)省一半磁盤空間
• 2.2 單個(gè)數(shù)據(jù)走索引查詢，自增id和uuid相差不大
• 2.3 范圍like查詢，自增ID性能優(yōu)于UUID
• 2.4 寫入測(cè)試，自增ID是UUID的4倍
• 2.5、備份和恢復(fù)，自增ID性能優(yōu)于UUID
• 500W總結(jié)
• 1000W總結(jié)
• 自增ID主鍵+步長(zhǎng)，適合中等規(guī)模的分布式場(chǎng)景
• UUID，適合小規(guī)模的分布式環(huán)境

一、準(zhǔn)備表&數(shù)據(jù)

UC_USER，自增ID為主鍵，表結(jié)構(gòu)類似如下：

CREATE TABLE `UC_USER` (
  `ID` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主鍵',
  `USER_NAME` varchar(100) DEFAULT NULL COMMENT '用戶名',
  `USER_PWD` varchar(200) DEFAULT NULL COMMENT '密碼',
  `BIRTHDAY` datetime DEFAULT NULL COMMENT '生日',
  `NAME` varchar(200) DEFAULT NULL COMMENT '姓名',
  `USER_ICON` varchar(500) DEFAULT NULL COMMENT '頭像圖片',
  `SEX` char(1) DEFAULT NULL COMMENT '性別, 1:男，2:女，3：保密',
  `NICKNAME` varchar(200) DEFAULT NULL COMMENT '昵稱',
  `STAT` varchar(10) DEFAULT NULL COMMENT '用戶狀態(tài)，01:正常，02:凍結(jié)',
  `USER_MALL` bigint(20) DEFAULT NULL COMMENT '當(dāng)前所屬M(fèi)ALL',
  `LAST_LOGIN_DATE` datetime DEFAULT NULL COMMENT '最后登錄時(shí)間',
  `LAST_LOGIN_IP` varchar(100) DEFAULT NULL COMMENT '最后登錄IP',
  `SRC_OPEN_USER_ID` bigint(20) DEFAULT NULL COMMENT '來(lái)源的聯(lián)合登錄',
  `EMAIL` varchar(200) DEFAULT NULL COMMENT '郵箱',
  `MOBILE` varchar(50) DEFAULT NULL COMMENT '手機(jī)',
  `IS_DEL` char(1) DEFAULT '0' COMMENT '是否刪除',
  `IS_EMAIL_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否綁定郵箱',
  `IS_PHONE_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否綁定手機(jī)',
  `CREATER` bigint(20) DEFAULT NULL COMMENT '創(chuàng)建人',
  `CREATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '注冊(cè)時(shí)間',
  `UPDATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '修改日期',
  `PWD_INTENSITY` char(1) DEFAULT NULL COMMENT '密碼強(qiáng)度',
  `MOBILE_TGC` char(64) DEFAULT NULL COMMENT '手機(jī)登錄標(biāo)識(shí)',
  `MAC` char(64) DEFAULT NULL COMMENT 'mac地址',
  `SOURCE` char(1) DEFAULT '0' COMMENT '1:WEB,2:IOS,3:ANDROID,4:WIFI,5:管理系統(tǒng), 0:未知',
  `ACTIVATE` char(1) DEFAULT '1' COMMENT '激活，1：激活，0：未激活',
  `ACTIVATE_TYPE` char(1) DEFAULT '0' COMMENT '激活類型，0：自動(dòng)，1：手動(dòng)',
  PRIMARY KEY (`ID`),
  UNIQUE KEY `USER_NAME` (`USER_NAME`),
  KEY `MOBILE` (`MOBILE`),
  KEY `IDX_MOBILE_TGC` (`MOBILE_TGC`,`ID`),
  KEY `IDX_EMAIL` (`EMAIL`,`ID`),
  KEY `IDX_CREATE_DATE` (`CREATE_DATE`,`ID`),
  KEY `IDX_UPDATE_DATE` (`UPDATE_DATE`)
) ENGINE=InnoDB AUTO_INCREMENT=7122681 DEFAULT CHARSET=utf8 COMMENT='用戶表'

UC_USER_PK_VARCHAR表，字符串ID為主鍵，采用uuid：

CREATE TABLE `UC_USER_PK_VARCHAR_1` (
  `ID` varchar(36) CHARACTER SET utf8mb4 NOT NULL DEFAULT '0' COMMENT '主鍵',
  `USER_NAME` varchar(100) DEFAULT NULL COMMENT '用戶名',
  `USER_PWD` varchar(200) DEFAULT NULL COMMENT '密碼',
  `BIRTHDAY` datetime DEFAULT NULL COMMENT '生日',
  `NAME` varchar(200) DEFAULT NULL COMMENT '姓名',
  `USER_ICON` varchar(500) DEFAULT NULL COMMENT '頭像圖片',
  `SEX` char(1) DEFAULT NULL COMMENT '性別, 1:男，2:女，3：保密',
  `NICKNAME` varchar(200) DEFAULT NULL COMMENT '昵稱',
  `STAT` varchar(10) DEFAULT NULL COMMENT '用戶狀態(tài)，01:正常，02:凍結(jié)',
  `USER_MALL` bigint(20) DEFAULT NULL COMMENT '當(dāng)前所屬M(fèi)ALL',
  `LAST_LOGIN_DATE` datetime DEFAULT NULL COMMENT '最后登錄時(shí)間',
  `LAST_LOGIN_IP` varchar(100) DEFAULT NULL COMMENT '最后登錄IP',
  `SRC_OPEN_USER_ID` bigint(20) DEFAULT NULL COMMENT '來(lái)源的聯(lián)合登錄',
  `EMAIL` varchar(200) DEFAULT NULL COMMENT '郵箱',
  `MOBILE` varchar(50) DEFAULT NULL COMMENT '手機(jī)',
  `IS_DEL` char(1) DEFAULT '0' COMMENT '是否刪除',
  `IS_EMAIL_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否綁定郵箱',
  `IS_PHONE_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否綁定手機(jī)',
  `CREATER` bigint(20) DEFAULT NULL COMMENT '創(chuàng)建人',
  `CREATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '注冊(cè)時(shí)間',
  `UPDATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '修改日期',
  `PWD_INTENSITY` char(1) DEFAULT NULL COMMENT '密碼強(qiáng)度',
  `MOBILE_TGC` char(64) DEFAULT NULL COMMENT '手機(jī)登錄標(biāo)識(shí)',
  `MAC` char(64) DEFAULT NULL COMMENT 'mac地址',
  `SOURCE` char(1) DEFAULT '0' COMMENT '1:WEB,2:IOS,3:ANDROID,4:WIFI,5:管理系統(tǒng), 0:未知',
  `ACTIVATE` char(1) DEFAULT '1' COMMENT '激活，1：激活，0：未激活',
  `ACTIVATE_TYPE` char(1) DEFAULT '0' COMMENT '激活類型，0：自動(dòng)，1：手動(dòng)',
  PRIMARY KEY (`ID`),
  UNIQUE KEY `USER_NAME` (`USER_NAME`),
  KEY `MOBILE` (`MOBILE`),
  KEY `IDX_MOBILE_TGC` (`MOBILE_TGC`,`ID`),
  KEY `IDX_EMAIL` (`EMAIL`,`ID`),
  KEY `IDX_CREATE_DATE` (`CREATE_DATE`,`ID`),
  KEY `IDX_UPDATE_DATE` (`UPDATE_DATE`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用戶表';

二、500w級(jí)數(shù)據(jù)測(cè)試

# 自增id為主鍵的表

mysql> select count(1) from UC_USER;

+----------+

| count(1) |

+----------+

|  5720112 |

+----------+

1 row in set (0.00 sec)

 

# uuid為主鍵的表

mysql> select count(1) from UC_USER_PK_VARCHAR_1;

+----------+

| count(1) |

+----------+

|  5720112 |

+----------+

1 row in set (1.91 sec)

2.1 錄入500W數(shù)據(jù)，自增ID節(jié)省一半磁盤空間

占據(jù)的空間容量來(lái)看，自增ID比UUID小一半左右。

2.2 單個(gè)數(shù)據(jù)走索引查詢，自增id和uuid相差不大

2.3 范圍like查詢，自增ID性能優(yōu)于UUID

2.4 寫入測(cè)試，自增ID是UUID的4倍

2.5、備份和恢復(fù)，自增ID性能優(yōu)于UUID

500W總結(jié)

在500W記錄表的測(cè)試下：

（1） 普通單條或者20條左右的記錄檢索，uuid為主鍵的相差不大幾乎效率相同；

（2） 但是范圍查詢特別是上百成千條的記錄查詢，自增id的效率要大于uuid；

（3） 在范圍查詢做統(tǒng)計(jì)匯總的時(shí)候，自增id的效率要大于uuid；

（4） 在存儲(chǔ)上面，自增id所占的存儲(chǔ)空間是uuid的1/2；

（5） 在備份恢復(fù)上，自增ID主鍵稍微優(yōu)于UUID。

1000W總結(jié)

在1000W記錄表的測(cè)試下：

（1）普通單條或者20條左右的記錄檢索，自增主鍵效率是uuid主鍵的2到3倍；

（2）但是范圍查詢特別是上百成千條的記錄查詢，自增id的效率要大于uuid；

（3）在范圍查詢做統(tǒng)計(jì)匯總的時(shí)候，自增id主鍵的效率是uuid主鍵1.5到2倍；

（4）在存儲(chǔ)上面，自增id所占的存儲(chǔ)空間是uuid的1/2；

（5）在寫入上面，自增ID主鍵的效率是UUID主鍵的3到10倍，相差比較明顯，特別是update小范圍之內(nèi)的數(shù)據(jù)上面。

（6）在備份恢復(fù)上，自增ID主鍵稍微優(yōu)于UUID。

自增ID主鍵+步長(zhǎng)，適合中等規(guī)模的分布式場(chǎng)景

在每個(gè)集群節(jié)點(diǎn)組的master上面，設(shè)置（auto_increment_increment），讓目前每個(gè)集群的起始點(diǎn)錯(cuò)開(kāi) 1，步長(zhǎng)選擇大于將來(lái)基本不可能達(dá)到的切分集群數(shù)，達(dá)到將 ID 相對(duì)分段的效果來(lái)滿足全局唯一的效果。

• 優(yōu)點(diǎn)是：實(shí)現(xiàn)簡(jiǎn)單，后期維護(hù)簡(jiǎn)單，對(duì)應(yīng)用透明。

• 缺點(diǎn)是：第一次設(shè)置相對(duì)較為復(fù)雜，因?yàn)橐槍?duì)未來(lái)業(yè)務(wù)的發(fā)展而計(jì)算好足夠的步長(zhǎng);

UUID，適合小規(guī)模的分布式環(huán)境

對(duì)于InnoDB這種聚集主鍵類型的引擎來(lái)說(shuō)，數(shù)據(jù)會(huì)按照主鍵進(jìn)行排序，由于UUID的無(wú)序性，InnoDB會(huì)產(chǎn)生巨大的IO壓力，而且由于索引和數(shù)據(jù)存儲(chǔ)在一起，字符串做主鍵會(huì)造成存儲(chǔ)空間增大一倍。

在存儲(chǔ)和檢索的時(shí)候，innodb會(huì)對(duì)主鍵進(jìn)行物理排序，這對(duì)auto_increment_int是個(gè)好消息，因?yàn)楹笠淮尾迦氲闹麈I位置總是在最后。

但是對(duì)uuid來(lái)說(shuō)，這卻是個(gè)壞消息，因?yàn)閡uid是雜亂無(wú)章的，每次插入的主鍵位置是不確定的，可能在開(kāi)頭，也可能在中間，在進(jìn)行主鍵物理排序的時(shí)候，勢(shì)必會(huì)造成大量的 IO操作影響效率，在數(shù)據(jù)量不停增長(zhǎng)的時(shí)候，特別是數(shù)據(jù)量上了千萬(wàn)記錄的時(shí)候，讀寫性能下降的非常厲害。

• 優(yōu)點(diǎn)：搭建比較簡(jiǎn)單，不需要為主鍵唯一性的處理。

• 缺點(diǎn)：占用兩倍的存儲(chǔ)空間（在云上光存儲(chǔ)一塊就要多花2倍的錢），后期讀寫性能下降厲害。

來(lái)源：blog.csdn.net/qq_30108237/article/details/106856051