不同数据量下主键类型的选择

阳光穿透心脏的1/2处 2021-10-01 00:26 256阅读 0赞

# 背景 #

之前面试的时候，有几家公司都问了UUID，自增ID的优点以及缺点，个人当时只考虑到了索引方面（增删查改的效率），没有考虑到分布式情况下的问题。

如果未来可能对数据进行合并、转移，自增ID势必会发生主键重复问题。

跨步自增可以解决分布式问题，但是需要对充分考虑好跨域的步数。

UUID可以解决分布式问题，但是因为是varchar类型并且又很长，影响索引重组速度，又会大大影响增删改效率（随数据量变大到百万千万级时会慢慢接近自增ID）。

雪花算法可以得出一个int类型的ID，此ID可以直接进行排序，可以解决分布式问题，但是生成时需要注意机器ID等参数，因为生成的int值很大，在小项目运用时也会影响主键索引重组。

总之，根据当前数据量大小，再预测未来的数据量，然后选择最合适的主键类型，像人员信息表这类数据，做大之后未来就极有可能会涉及分布式和合表问题。

**另外，如果说有一种情况，某表内的数据一开始在某个系统里以自增为主键的时候，插入时顺便也生成一个UUID存放到一个临时字段里，数据转移时将此表内的数据和结构先克隆为另外一个新表，然后把新表的自增ID删除，将UUID那个字段设置成主键后再合并到新系统的表中，这样是不是即不影响之前的系统效率，也防止了分布式主键冲突的问题？**

--------------------

# 测试部分： #

###  1、准备表以及数据 ###

UC\_USER，自增ID为主键，表结构类似如下：

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 '用户状态，01:正常，02:冻结',
      `USER_MALL` bigint(20) DEFAULT NULL COMMENT '当前所属MALL',
      `LAST_LOGIN_DATE` datetime DEFAULT NULL COMMENT '最后登录时间',
      `LAST_LOGIN_IP` varchar(100) DEFAULT NULL COMMENT '最后登录IP',
      `SRC_OPEN_USER_ID` bigint(20) DEFAULT NULL COMMENT '来源的联合登录',
      `EMAIL` varchar(200) DEFAULT NULL COMMENT '邮箱',
      `MOBILE` varchar(50) DEFAULT NULL COMMENT '手机',
      `IS_DEL` char(1) DEFAULT '0' COMMENT '是否删除',
      `IS_EMAIL_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定邮箱',
      `IS_PHONE_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定手机',
      `CREATER` bigint(20) DEFAULT NULL COMMENT '创建人',
      `CREATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间',
      `UPDATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '修改日期',
      `PWD_INTENSITY` char(1) DEFAULT NULL COMMENT '密码强度',
      `MOBILE_TGC` char(64) DEFAULT NULL COMMENT '手机登录标识',
      `MAC` char(64) DEFAULT NULL COMMENT 'mac地址',
      `SOURCE` char(1) DEFAULT '0' COMMENT '1:WEB,2:IOS,3:ANDROID,4:WIFI,5:管理系统, 0:未知',
      `ACTIVATE` char(1) DEFAULT '1' COMMENT '激活，1：激活，0：未激活',
      `ACTIVATE_TYPE` char(1) DEFAULT '0' COMMENT '激活类型，0：自动，1：手动',
      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 '用户状态，01:正常，02:冻结',
      `USER_MALL` bigint(20) DEFAULT NULL COMMENT '当前所属MALL',
      `LAST_LOGIN_DATE` datetime DEFAULT NULL COMMENT '最后登录时间',
      `LAST_LOGIN_IP` varchar(100) DEFAULT NULL COMMENT '最后登录IP',
      `SRC_OPEN_USER_ID` bigint(20) DEFAULT NULL COMMENT '来源的联合登录',
      `EMAIL` varchar(200) DEFAULT NULL COMMENT '邮箱',
      `MOBILE` varchar(50) DEFAULT NULL COMMENT '手机',
      `IS_DEL` char(1) DEFAULT '0' COMMENT '是否删除',
      `IS_EMAIL_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定邮箱',
      `IS_PHONE_CONFIRMED` char(1) DEFAULT '0' COMMENT '是否绑定手机',
      `CREATER` bigint(20) DEFAULT NULL COMMENT '创建人',
      `CREATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间',
      `UPDATE_DATE` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '修改日期',
      `PWD_INTENSITY` char(1) DEFAULT NULL COMMENT '密码强度',
      `MOBILE_TGC` char(64) DEFAULT NULL COMMENT '手机登录标识',
      `MAC` char(64) DEFAULT NULL COMMENT 'mac地址',
      `SOURCE` char(1) DEFAULT '0' COMMENT '1:WEB,2:IOS,3:ANDROID,4:WIFI,5:管理系统, 0:未知',
      `ACTIVATE` char(1) DEFAULT '1' COMMENT '激活，1：激活，0：未激活',
      `ACTIVATE_TYPE` char(1) DEFAULT '0' COMMENT '激活类型，0：自动，1：手动',
      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='用户表';

# #

## 2、500W数据测试 ##

### 2.1 录入500W数据，自增ID节省一半磁盘空间 ###

确定两个表数据量

# 自增id为主键的表
    
    mysql> select count(1) from UC_USER;
    
    +----------+
    
    | count(1) |
    
    +----------+
    
    |  5720112 |
    
    +----------+
    
    1 row in set (0.00 sec)
    
     
    
    mysql>
    
     
    
    # uuid为主键的表
    
    mysql> select count(1) from UC_USER_PK_VARCHAR_1;
    
    +----------+
    
    | count(1) |
    
    +----------+
    
    |  5720112 |
    
    +----------+
    
    1 row in set (1.91 sec)

占据的空间容量来看，自增ID比UUID小一半左右。

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> 主键类型 </td> 
 <td style="vertical-align:top;"> 数据文件大小 </td> 
 <td style="vertical-align:top;"> 占据容量&nbsp; </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 自增ID </td> 
 <td style="vertical-align:top;"> -rw-rw---- 1 mysql mysql 4.2G Aug 20 23:08 UC_USER_1.ibd </td> 
 <td style="vertical-align:top;"> 4.2 G </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> UUID </td> 
 <td style="vertical-align:top;"> -rw-rw---- 1 mysql mysql 8.8G Aug 20 18:20 UC_USER_PK_VARCHAR_1.ibd </td> 
 <td style="vertical-align:top;"> 8.8 G </td> 
 </tr> 
 </tbody> 
</table>

### 4.2 单个数据走索引查询，自增id和 uuid效率比是：(2~3):1 ###

### 4.3 范围like查询，自增ID性能优于UUID，比值(1.5~2)：1 ###

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> 主键类型 </td> 
 <td style="vertical-align:top;"> SQL语句 </td> 
 <td style="vertical-align:top;"> 执行时间 (秒) </td> 
 </tr> 
 <tr> 
 <td colspan="3" style="vertical-align:top;"> &nbsp; （1）模糊范围查询1000条数据，自增ID性能要好于UUID </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 自增ID </td> 
 <td style="vertical-align:top;"> SELECT SQL_NO_CACHE t.* FROM test.`UC_USER` t WHERE t.`MOBILE` LIKE '147%' LIMIT 1000; </td> 
 <td style="vertical-align:top;"> 2.398 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> UUID </td> 
 <td style="vertical-align:top;"> SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`MOBILE` LIKE '147%' LIMIT 1000; </td> 
 <td style="vertical-align:top;"> 5.872 </td> 
 </tr> 
 <tr> 
 <td colspan="3" style="vertical-align:top;"> &nbsp; （2）日期范围查询20条数据，自增ID稍微弱于UUID </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 自增ID </td> 
 <td style="vertical-align:top;"> SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_1` t WHERE t.`CREATE_DATE` &gt; '2016-08-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 20; </td> 
 <td style="vertical-align:top;"> 0.765 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> UUID </td> 
 <td style="vertical-align:top;"> SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` &gt; '2016-08-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 20; </td> 
 <td style="vertical-align:top;"> 1.090 </td> 
 </tr> 
 <tr> 
 <td colspan="3" style="vertical-align:top;"> &nbsp; （3）范围查询200条数据，自增ID性能要好于UUID </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 自增ID </td> 
 <td style="vertical-align:top;"> SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_1` t WHERE t.`CREATE_DATE` &gt; '2016-07-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 200; </td> 
 <td style="vertical-align:top;"> 1.569 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> UUID </td> 
 <td style="vertical-align:top;"> SELECT SQL_NO_CACHE t.* FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` &gt; '2016-07-01 10:26:36' ORDER BY t.`UPDATE_DATE` DESC LIMIT 200; </td> 
 <td style="vertical-align:top;"> 2.597 </td> 
 </tr> 
 <tr> 
 <td colspan="3" style="vertical-align:top;"> &nbsp; 范围查询总数量，自增ID要好于UUID </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 自增ID </td> 
 <td style="vertical-align:top;"> SELECT SQL_NO_CACHE COUNT(1) FROM test.`UC_USER_1` t WHERE t.`CREATE_DATE` &gt; '2016-07-01 10:26:36'&nbsp; ; </td> 
 <td style="vertical-align:top;"> 1.129 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> UUID </td> 
 <td style="vertical-align:top;"> SELECT SQL_NO_CACHE COUNT(1) FROM test.`UC_USER_PK_VARCHAR_1` t WHERE t.`CREATE_DATE` &gt; '2016-07-01 10:26:36'&nbsp; ; </td> 
 <td style="vertical-align:top;"> 2.302 </td> 
 </tr> 
 </tbody> 
</table>

### 4.4 写入测试，自增ID比UUID效率高，比值(3~10)：1 ###

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> 主键类型 </td> 
 <td style="vertical-align:top;"> SQL语句 </td> 
 <td style="vertical-align:top;"> 执行时间 (秒) </td> 
 </tr> 
 <tr> 
 <td colspan="3" style="vertical-align:top;"> &nbsp; &nbsp; 修改一天的记录 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 自增ID </td> 
 <td style="vertical-align:top;"> UPDATE test.`UC_USER_1` t SET t.`MOBILE_TGC`='T2' WHERE t.`CREATE_DATE` &gt; '2016-05-03 10:26:36' AND t.`CREATE_DATE` &lt;'2016-05-04 00:00:00'&nbsp; ; </td> 
 <td style="vertical-align:top;"> 2.685 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> UUID </td> 
 <td style="vertical-align:top;"> UPDATE test.`UC_USER_PK_VARCHAR_1` t SET t.`MOBILE_TGC`='T2' WHERE t.`CREATE_DATE` &gt; '2016-05-03 10:26:36' AND t.`CREATE_DATE` &lt;'2016-05-04 00:00:00'&nbsp; ; </td> 
 <td style="vertical-align:top;"> 26.521 </td> 
 </tr> 
 <tr> 
 <td colspan="3" style="vertical-align:top;"> &nbsp; 录入数据 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> 自增ID </td> 
 <td style="vertical-align:top;"> INSERT INTO test.`UC_USER_1`(&nbsp;&nbsp; ID,&nbsp;&nbsp; `USER_NAME`,&nbsp;&nbsp; `USER_PWD`,&nbsp;&nbsp; `BIRTHDAY`,&nbsp;&nbsp; `NAME`,&nbsp;&nbsp; `USER_ICON`,&nbsp;&nbsp; `SEX`,&nbsp;&nbsp; `NICKNAME`,&nbsp;&nbsp; `STAT`,&nbsp;&nbsp; `USER_MALL`,&nbsp;&nbsp; `LAST_LOGIN_DATE`,&nbsp;&nbsp; `LAST_LOGIN_IP`,&nbsp;&nbsp; `SRC_OPEN_USER_ID`,&nbsp;&nbsp; `EMAIL`,&nbsp;&nbsp; `MOBILE`,&nbsp;&nbsp; `IS_DEL`,&nbsp;&nbsp; `IS_EMAIL_CONFIRMED`,&nbsp;&nbsp; `IS_PHONE_CONFIRMED`,&nbsp;&nbsp; `CREATER`,&nbsp;&nbsp; `CREATE_DATE`,&nbsp;&nbsp; `UPDATE_DATE`,&nbsp;&nbsp; `PWD_INTENSITY`,&nbsp;&nbsp; `MOBILE_TGC`,&nbsp;&nbsp; `MAC`,&nbsp;&nbsp; `SOURCE`,&nbsp;&nbsp; `ACTIVATE`,&nbsp;&nbsp; `ACTIVATE_TYPE` ) SELECT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NULL,&nbsp;&nbsp;&nbsp; CONCAT('110',`USER_NAME`,8),&nbsp;&nbsp; `USER_PWD`,&nbsp;&nbsp; `BIRTHDAY`,&nbsp;&nbsp; `NAME`,&nbsp;&nbsp; `USER_ICON`,&nbsp;&nbsp; `SEX`,&nbsp;&nbsp; `NICKNAME`,&nbsp;&nbsp; `STAT`,&nbsp;&nbsp; `USER_MALL`,&nbsp;&nbsp; `LAST_LOGIN_DATE`,&nbsp;&nbsp; `LAST_LOGIN_IP`,&nbsp;&nbsp; `SRC_OPEN_USER_ID`,&nbsp;&nbsp; `EMAIL`, CONCAT('110',TRIM(`MOBILE`)),&nbsp;&nbsp; `IS_DEL`,&nbsp;&nbsp; `IS_EMAIL_CONFIRMED`,&nbsp;&nbsp; `IS_PHONE_CONFIRMED`,&nbsp;&nbsp; `CREATER`,&nbsp;&nbsp; `CREATE_DATE`,&nbsp;&nbsp; `UPDATE_DATE`,&nbsp;&nbsp; `PWD_INTENSITY`,&nbsp;&nbsp; `MOBILE_TGC`,&nbsp;&nbsp; `MAC`,&nbsp;&nbsp; `SOURCE`,&nbsp;&nbsp; `ACTIVATE`,&nbsp;&nbsp; `ACTIVATE_TYPE` FROM `test`.`UC_USER_1` LIMIT 100; </td> 
 <td style="vertical-align:top;"> 0.534 </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> UUID </td> 
 <td style="vertical-align:top;"> INSERT INTO test.`UC_USER_PK_VARCHAR_1`(&nbsp;&nbsp;&nbsp; ID,&nbsp;&nbsp; `USER_NAME`,&nbsp;&nbsp; `USER_PWD`,&nbsp;&nbsp; `BIRTHDAY`,&nbsp;&nbsp; `NAME`,&nbsp;&nbsp; `USER_ICON`,&nbsp;&nbsp; `SEX`,&nbsp;&nbsp; `NICKNAME`,&nbsp;&nbsp; `STAT`,&nbsp;&nbsp; `USER_MALL`,&nbsp;&nbsp; `LAST_LOGIN_DATE`,&nbsp;&nbsp; `LAST_LOGIN_IP`,&nbsp;&nbsp; `SRC_OPEN_USER_ID`,&nbsp;&nbsp; `EMAIL`,&nbsp;&nbsp; `MOBILE`,&nbsp;&nbsp; `IS_DEL`,&nbsp;&nbsp; `IS_EMAIL_CONFIRMED`,&nbsp;&nbsp; `IS_PHONE_CONFIRMED`,&nbsp;&nbsp; `CREATER`,&nbsp;&nbsp; `CREATE_DATE`,&nbsp;&nbsp; `UPDATE_DATE`,&nbsp;&nbsp; `PWD_INTENSITY`,&nbsp;&nbsp; `MOBILE_TGC`,&nbsp;&nbsp; `MAC`,&nbsp;&nbsp; `SOURCE`,&nbsp;&nbsp; `ACTIVATE`,&nbsp;&nbsp; `ACTIVATE_TYPE` ) SELECT&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UUID(),&nbsp;&nbsp; CONCAT('110',`USER_NAME`,8),&nbsp;&nbsp; `USER_PWD`,&nbsp;&nbsp; `BIRTHDAY`,&nbsp;&nbsp; `NAME`,&nbsp;&nbsp; `USER_ICON`,&nbsp;&nbsp; `SEX`,&nbsp;&nbsp; `NICKNAME`,&nbsp;&nbsp; `STAT`,&nbsp;&nbsp; `USER_MALL`,&nbsp;&nbsp; `LAST_LOGIN_DATE`,&nbsp;&nbsp; `LAST_LOGIN_IP`,&nbsp;&nbsp; `SRC_OPEN_USER_ID`,&nbsp;&nbsp; `EMAIL`, CONCAT('110',TRIM(`MOBILE`)),&nbsp;&nbsp; `IS_DEL`,&nbsp;&nbsp; `IS_EMAIL_CONFIRMED`,&nbsp;&nbsp; `IS_PHONE_CONFIRMED`,&nbsp;&nbsp; `CREATER`,&nbsp;&nbsp; `CREATE_DATE`,&nbsp;&nbsp; `UPDATE_DATE`,&nbsp;&nbsp; `PWD_INTENSITY`,&nbsp;&nbsp; `MOBILE_TGC`,&nbsp;&nbsp; `MAC`,&nbsp;&nbsp; `SOURCE`,&nbsp;&nbsp; `ACTIVATE`,&nbsp;&nbsp; `ACTIVATE_TYPE` FROM `test`.`UC_USER_1` LIMIT 100; </td> 
 <td style="vertical-align:top;"> 1.716 </td> 
 </tr> 
 </tbody> 
</table>

### 4.5、备份和恢复，自增ID性能优于UUID ###

## 5、1000W总结 ##

**在1000W记录表的测试下：**

（1）普通单条或者20条左右的记录检索，自增主键效率是uuid主键的2到3倍；

（2）但是范围查询特别是上百成千条的记录查询，自增id的效率要大于uuid；

（3）在范围查询做统计汇总的时候，自增id主键的效率是uuid主键1.5到2倍；

（4）在存储上面，自增id所占的存储空间是uuid的1/2；

（5）在写入上面，自增ID主键的效率是UUID主键的3到10倍，相差比较明显，特别是update小范围之内的数据上面。

（6）在备份恢复上，自增ID主键稍微优于UUID。

## 6、MySQL分布式架构的取舍 ##

分布式架构，意味着需要多个实例中保持一个表的主键的唯一性。这个时候普通的单表自增ID主键就不太合适，因为多个mysql实例上会遇到主键全局唯一性问题。

### 6.1、自增ID主键+步长，适合中等规模的分布式场景 ###

在每个集群节点组的master上面，设置（auto\_increment\_increment），让目前每个集群的起始点错开 1，步长选择大于将来基本不可能达到的切分集群数，达到将 ID 相对分段的效果来满足全局唯一的效果。

优点是：实现简单，后期维护简单，对应用透明。

缺点是：第一次设置相对较为复杂，因为要针对未来业务的发展而计算好足够的步长;

**规划：**

比如计划总共N个节点组，那么第i个节点组的my.cnf的配置为：

auto\_increment\_offset  i

auto\_increment\_increment  N

假如规划48个节点组，N为48，现在配置第8个节点组，这个i为8，第8个节点组的my.cnf里面的配置为：

auto\_increment\_offset  8

auto\_increment\_increment  48

### 6.2、UUID，适合小规模的分布式环境 ###

对于InnoDB这种聚集主键类型的引擎来说，数据会按照主键进行排序，由于UUID的无序性，InnoDB会产生巨大的IO压力，而且由于索引和数据存储在一起，字符串做主键会造成存储空间增大一倍。

在存储和检索的时候，innodb会对主键进行物理排序，这对auto\_increment\_int是个好消息，因为后一次插入的主键位置总是在最后。但是对uuid来说，这却是个坏消息，因为uuid是杂乱无章的，每次插入的主键位置是不确定的，可能在开头，也可能在中间，在进行主键物理排序的时候，势必会造成大量的 IO操作影响效率，在数据量不停增长的时候，特别是数据量上了千万记录的时候，读写性能下降的非常厉害。

优点：搭建比较简单，不需要为主键唯一性的处理。

缺点：占用两倍的存储空间（在云上光存储一块就要多花2倍的钱），后期读写性能下降厉害。

### 6.3、雪花算法自造全局自增ID，适合大数据环境的分布式场景 ###

由twitter公布的开源的分布式id算法snowflake（Java版本）

**IdWorker.java：**

package com.demo.elk;
 
 import org.slf4j.Logger; 
 
 import org.slf4j.LoggerFactory;
 
 
 
 public class IdWorker {
 
 
 
 protected static final Logger LOG = LoggerFactory.getLogger(IdWorker.class);
 
 
 
 private long workerId;
 
 private long datacenterId;
 
 private long sequence = 0L;
 
 
 
 private long twepoch = 1288834974657L;
 
 
 
 private long workerIdBits = 5L;
 
 private long datacenterIdBits = 5L;
 
 private long maxWorkerId = -1L ^ (-1L << workerIdBits);
 
 private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
 
 private long sequenceBits = 12L;
 
 
 
 private long workerIdShift = sequenceBits;
 
 private long datacenterIdShift = sequenceBits + workerIdBits;
 
 private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
 
 private long sequenceMask = -1L ^ (-1L << sequenceBits);
 
 
 
 private long lastTimestamp = -1L;
 
 
 
 public IdWorker(long workerId, long datacenterId) {
 
 // sanity check for workerId
 
 if (workerId > maxWorkerId || workerId < 0) {
 
 throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
 
 }
 
 if (datacenterId > maxDatacenterId || datacenterId < 0) {
 
 throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
 
 }
 
 this.workerId = workerId;
 
 this.datacenterId = datacenterId;
 
 LOG.info(String.format("worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d", timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId));
 
 }
 
 
 
 public synchronized long nextId() {
 
 long timestamp = timeGen();
 
 
 
 if (timestamp < lastTimestamp) {
 
 LOG.error(String.format("clock is moving backwards. Rejecting requests until %d.", lastTimestamp));
 
 throw new RuntimeException(String.format("Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
 
 }
 
 
 
 if (lastTimestamp == timestamp) {
 
 sequence = (sequence + 1) & sequenceMask;
 
 if (sequence == 0) {
 
 timestamp = tilNextMillis(lastTimestamp);
 
 }
 
 } else {
 
 sequence = 0L;
 
 }
 
 
 
 lastTimestamp = timestamp;
 
 
 
 return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId << datacenterIdShift) | (workerId << workerIdShift) | sequence;
 
 }
 
 
 
 protected long tilNextMillis(long lastTimestamp) {
 
 long timestamp = timeGen();
 
 while (timestamp <= lastTimestamp) {
 
 timestamp = timeGen();
 
 }
 
 return timestamp;
 
 }
 
 
 
 protected long timeGen() {
 
 return System.currentTimeMillis();
 
 }
 
 }

**测试生成ID的测试类，IdWorkerTest.java：**

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> package com.demo.elk; &nbsp; import java.util.HashSet; import java.util.Set; &nbsp; public class IdWorkerTest { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; static class IdWorkThread implements Runnable { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; private Set&lt;Long&gt; set; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; private IdWorker idWorker; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public IdWorkThread(Set&lt;Long&gt; set, IdWorker idWorker) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this.set = set; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this.idWorker = idWorker; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public void run() { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; while (true) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;long id = idWorker.nextId(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; System.out.println("&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; real id:" + id); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (!set.add(id)) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; System.out.println("duplicate:" + id); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; } &nbsp; &nbsp;&nbsp;&nbsp; public static void main(String[] args) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Set&lt;Long&gt; set = new HashSet&lt;Long&gt;(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; final IdWorker idWorker1 = new IdWorker(0, 0); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; final IdWorker idWorker2 = new IdWorker(1, 0); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thread t1 = new Thread(new IdWorkThread(set, idWorker1)); &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Thread t2 = new Thread(new IdWorkThread(set, idWorker2)); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; t1.setDaemon(true); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; t2.setDaemon(true); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; t1.start(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; t2.start(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; try { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Thread.sleep(30000); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } catch (InterruptedException e) { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;e.printStackTrace(); &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; } } </td> 
 </tr> 
 </tbody> 
</table>

## 7，总结 ##

**（1）单实例或者单节点组：**

经过500W、1000W的单机表测试，自增ID相对UUID来说，自增ID主键性能高于UUID，磁盘存储费用比UUID节省一半的钱。所以在单实例上或者单节点组上，使用自增ID作为首选主键。

**（2）分布式架构场景：**

20个节点组下的小型规模的分布式场景，为了快速实现部署，可以采用多花存储费用、牺牲部分性能而使用UUID主键快速部署；

20到200个节点组的中等规模的分布式场景，可以采用自增ID+步长的较快速方案。

*         200以上节点组的大数据下的分布式场景，可以借鉴类似twitter雪花算法构造的全局自增ID作为主键。*