mysql 自增id
自增id 缺点 ：
1 mysql insert 后 必须 SELECT LAST_INSERT_ID() 才能返回 id 。 对于业务方而言 ， id 的生成以及返回逻辑 必须绑定mysql 。 id 自增这块逻辑肯定要加锁的 ，除此之外 ，主备切换 ，replace into 以及 其他的一些操作会导致id 生成连续性出现问题 。在同表高并发写的情况下 ， id 自增会存在性能瓶颈 。
优化 ： 将mysql id 生成 这一块从mysql 功能 独立出来 。能从本质上解决上面的问题 。
2 通常我们根据业务维度（假如说根据地区） ，对数据库进行数据分片 ， 自增id 会出现相同的情况 。 这时候 对于业务来说 ， 必须要 分片id + 自增id 才能定位 ，真实数据，才具备唯一性 。
优化： 全局唯一id
雪花id
image.png
1.第一位 占用1bit，其值始终是0，没有实际作用。 2.时间戳 占用41bit，精确到毫秒，总共可以容纳约69年的时间。 3.工作机器id 占用10bit，其中高位5bit是数据中心ID，低位5bit是工作节点ID，做多可以容纳1024个节点。 4.序列号 占用12bit，每个节点每毫秒0开始不断累加，最多可以累加到4095，一共可以产生4096个ID。
缺点
1在使用过程中 ，雪花id 工作机器id可能会出现问题 ，这个工作机器id 应该是和你的应用关联在一起 。 开发同学 可能根本就注意到这点 ，你的工作机器id 没有配置数据中心ID ，以及工作节点ID ， 会根据mac 地址 ， ip 地址去做一些计算 得到 工作机器id 。 问题就出在他这个算法上 ,会导致工作机器id重复。 可以参考mybatisplus github issue
https://github.com/baomidou/mybatis-plus/pull/2524
https://mp.weixin.qq.com/s/e-hEYALJXVKAP18WheJjRg
2 时钟回拨也会导致出现相同时间戳的情况 ， 比如服务器通过ntp同步时间
