关于数据库主键ID的选择

哈喽！今天心血来潮给大家带来了《关于数据库主键ID的选择》，想必大家应该对数据库都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到MySQL，若是你正在学习数据库，千万别错过这篇文章~希望能帮助到你！

一、如何选择

在mysql中，我们要查询一条或多条数据，都会通过索引来更快的查询数据，通常每条数据都会有一个主键ID用来构建索引方便查询。
由于
那么主键ID该选怎么选呢？

二、自增主键ID

自增主键ID通常都会选择int类型或者long类型。

它的优点是:
简单方便，有序递增，方便排序和分页等。

缺点：
1.随着业务的增长，当id达到int最大值或者long最大值时，服务将不可用，存在上限问题。
2.简单递增容易被其他人猜测利用，通过id数来判断新增多少条数据或是用做他途。
3.根据业务需要分库分表时，会有id重复等问题。

试用场景：比较适合数据量不多，并发量比较小的情况下使用。

三、UUID

UUID是通用唯一识别码（Universally Unique Identifier)的缩写，开放软件基金会(OSF)规范定义了包括网卡MAC地址、时间戳、名字空间（Namespace）、随机或伪随机数、时序等元素。利用这些元素来生成UUID。

UUID是由128位二进制组成，一般转换成十六进制，然后用String表示。
java中自带UUID类,有4种不同的UUID的生成策略:

randomly : 基于随机数生成UUID，由于Java中的随机数是伪随机数，其重复的概率是可以被计算出来的。
time-based : 基于时间的UUID,这个一般是通过当前时间，随机数，和本地Mac地址来计算出来，自带的JDK包并没有这个算法的我们在一些UUIDUtil中，比如我们的log4j.core.util，会重新定义UUID的高位和低位。
DCE security : DCE安全的UUID。
name-based ：基于名字的UUID，通过计算名字和名字空间的MD5来计算UUID。

UUID的优点:
通过本地生成，没有经过网络I/O，性能较快
无序，无法预测生成顺序（也是缺点之一）。
不会出现重复

缺点：
使用字符串进行存储，占用一定的存储空间，需要排序的时候会比较麻烦，查询相对较慢

适用场景：可以为不需要担心过多的空间占用的情况下，以及不需要生成有递增趋势的数字的场景

四、雪花算法生成ID

该算法是推特开源的snowflake（雪花）算法，用来生成分布式ID的。
其目的是生成一个64bit的整数:

1bit:一般是符号位，不做处理
41bit:从开始用的时间开始算，用来记录时间戳，这里可以记录69年。如果真用完了呢。。。那也是年轻人去解决的事了。。。
10bit:10bit用来记录机器ID，总共可以记录1024台机器，一般用前5位代表数据中心，后面5位是某个数据中心的机器ID
12bit:循环位，用来对同一个毫秒之内产生不同的ID，12位可以最多记录4095个，也就是在同一个机器同一毫秒最多记录4095个，多余的需要进行等待下毫秒。

优点：
整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID
作区分)，并且效率较高，经测试，SnowFlake每秒能够产生26万ID左右

缺点：
1.过分依赖机器时钟，如果机器时钟回拨，会导致重复ID生成
2.根据雪花算法，在单机上是绝对递增的，但是由于设计到分布式环境，每台机器上的时钟不可能完全同步，有时候会出现不是全局递增的情况（一般分布式ID只要求趋势递增，并不会严格要求递增。我觉得正常配置雪花算法的情况下国内并发量使用雪花算法出问题的公司不会有太多。。）

适用场景：应用在分布式系统中，适用于并发量大的场景。

五、结尾

根据自身系统服务的情况来选择生成的主键ID。上面三种我们公司都有用到，看了看数据库里的表，感觉头有点大。。

理论要掌握，实操不能落！以上关于《关于数据库主键ID的选择》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！