兄弟，数据库主键生成这事你说简单不简单？说简单吧，不就是找个唯一标识？说不简单吧，选不对方法分分钟让你抓狂！今天我就手把手带你搞懂这五大金刚，看看它们到底谁更适合你的项目！

问题一：你的系统需要全局唯一吗？

比如，如果兄弟们分布在全世界，那得用UUID，它是宇宙通行证，走到哪儿都不怕撞车！但如果只是个本地小系统，自增主键就省得天天加班了！

问题二：你爱不爱排序？

如果是电商搞订单，想按时间排序？那Redis或Snowflake就是你的情人！特别是Snowflake，时间+机器ID+流水号，让你的订单像秒表一样精准！

问题三：你的架构能支持Redis吗？

如果已经有Redis在场，那太好了，INCRBY直接上车！但如果得重新装Redis，那兄弟们得算算成本，值不值得了！

总之啊，别硬着头皮乱选！先看看你的系统是需要全球唯一，还是需要排序，或者架构能不能支持，这样选主键才是真英雄！

一 生成策略介绍

1.1 自增主键

设置auto_increment 实现数据表自增；

优点： 适合排序和分页

缺点：在分库分表中，保证每张表实现自增同时，不同表之间还得保证连续。实现比较麻烦。

1.2 uuid

UUID是由32个的16进制数字组成，所以每个UUID的长度是128位（16^32 = 2^128）。

优点： 全球唯一。

缺点：不能满足排序和保证趋势递增

https://www.cnblogs.com/haoxinyue/p/5208136.html

1.3 redis

利用单线程的原子操作， INCR和INCRBY来实现

优点：数字ID天然排序，对分页或者需要排序的结果很有帮助

缺点：现有架构没有安装redis，还需要单独安装。

1.4 tewitter的snowflake算法

snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是0。

优点：ID按照时间在单机上是递增的。

缺点：如果多个节点时钟不同步，需要进行时间回拨。

1.5 zk

zookeeper主要通过其znode数据版本来生成序列号，可以生成32位和64位的数据版本号，客户端可以使用这个版本号来作为唯一的序列号。