关于 mysql主键的选择

uuid的缺点

与自增相比，最大的缺陷就是随机io。这一点又要谈到我们的innodb了，因为这个默认引擎，表中数据是按照主键顺序存放的。也就是说，如果发生了随机io，那么就会频繁地移动磁盘块。当数据量大的时候，写的短板将非常明显。当然，这个缺点可以通过nosql那些产品解决。

即：

innodb 中的主键是聚簇索引，会把相邻主键的数据安放在相邻的物理存储上。如果主键不是自增，而是随机的，那么频繁的插入会使 innodb 频繁地移动磁盘块，而影响写入性能。

读取出来的数据也是没有规律的，通常需要order by，其实也很消耗数据库资源
看起来比较丑

 

所以使用雪花算法主键

雪花算法简单描述： 
+ 最高位是符号位，始终为0，不可用。 
+ 41位的时间序列，精确到毫秒级，41位的长度可以使用69年。时间位还有一个很重要的作用是可以根据时间进行排序。 
+ 10位的机器标识，10位的长度最多支持部署1024个节点。 
+ 12位的计数序列号，序列号即一系列的自增id，可以支持同一节点同一毫秒生成多个ID序号，12位的计数序列号支持每个节点每毫秒产生4096个ID序号。

看的出来，这个算法很简洁也很简单，但依旧是一个很好的ID生成策略。最高的那几位是时间戳，这能保证不管是几台机子在跑主键的生成必然是趋势自增的，基本上下一毫秒产生的主键必然比上一毫秒的大。最后的几位是加锁的方法生成的，一台机器一毫秒钟4096个，够用了吧？

 

这种方式的优缺点是：

优点：

• 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
• 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
• 可以根据自身业务特性分配bit位，非常灵活。

缺点：

• 强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。