很多在创业型公司或者在学校学习的时候，我们做毕业设计都喜欢使用自增主键。这个呢？其实是没有问题的，但是如果你是在阿里，华为，腾讯这样的大厂，自增主键往往是禁止使用的！因为自增主键，在分布式的数据环境下，它有着严重的问题，那我们来分析一下到底有什么问题呢。

很多公司会选择UUID替代自增主键。咱们先说一下什么是UUID？它是一个根据我们当前计算机时间以及各种特性所算出来的，一个在全世界范围内的唯一的一个128位长的字符串，它是唯一的且无序的。

如果你使用UUID作为主键的话，首先，它是128位，相比起我们常用的整型浪费空间，这是小事，最重要的，因为无序的特性会产生大量的索引重排，那什么是索引重排呢？我们都知道，作为主键，你一旦给他设置好以后，他就会自动的去建立这个唯一的主见索引。那么，主键索引在mysql的innoDB中存储的格式是这样的，它采用b+树的方式来进行数据的存储，所有的叶子节点按照顺序12345678向后依次进行排开，那假设当我们的新主键是有顺序，比如新增一条数据的时候，他只需要在原有的b+树，最后上面追加这个元素就可以啦。影响的数据的范围是非常小的，但是如果你使用的像UUID这样的，就涉及到大量的索引重排了。

举个例子，我假设以书籍名称的形式来模拟一下，当我们每次新增一个书籍名称的时候，因为采用的是字母表的顺序来进行的，所以新增的这个数据呢，它是在我们索引的某一个位置上来增加的，那么这个节点之后的所有节点，都会涉及到一个重排的工作。UUID就是这样，因为是无序的，我们新增了以后，因为所以要给它安排一个合理的位置，添加好以后，后面所有的数据都要去涉及重排，如果数据量一大。这个索引重排的代价其实是非常高的，所以作为UUID是不可以被用作主键的替代品的。

那怎么办呢？我们仔细思考一下。其实我们现在需要一种可以进行分布式且有序的主键生成算法。那在互联网业界中，已经有了一个成熟的实现，就是雪花算法。雪花算法是解决分布式id的一个高效的方案，大部分互联网公司都在使用雪花算法，当然还有公司自己实现其他的方案。

它的主要思路就是以时间作为依据，使用64位long类型的数据存储id，最高位一位存储0或者1,0代表整数，1代表负数，一般都是0，所以最高位不变，41位存储毫秒级时间戳，10位存储机器码，12存储序列号。这样最大2的10次方的机器，也就是1024台机器，最多每毫秒每台机器产生2的12次方也就是4096个id。这对于我们99%的厂商来说都已经足够了。那针对雪花算法的具体使用办法呢？其实我们自己是不用写的，因为在java中已经有了很多很多现成的实现。调用一个jar包就可以自动的去生成。

SnowFlake作为以后我们开发的过程中如果涉及到大表，尤其可能会之后分库，分表切分的话，那么。优先去使用雪花算法来进行，但是雪花算法它有一个注意事项就是注意时间回拨的问题，关注小东架构师，以后会讲到更多知识和解决办法！