背景
随着业务的增长，文章表可能要占用很大的物理存储空间，为了解决该问题，后期使用数据库分片技术。
将一个数据库进行拆分，通过数据库中间件连接。如果数据库中该表选用ID自增策略，则可能产生重复的ID，
此时应该使用分布式ID生成策略来生成ID。
技术选型
| 方案 | 优势 | 劣势 |
|---|---|---|
| Redis | (INCR)生成一个全局连续递增的类型主键 | 增加了一个外部组件的依赖，Redis不可用，则整个(INCR)生成一个全局连续递增的数字类数据库将无法在插入 |
| UUID | 全局唯一，Mysql也有UUID实现 | 36个字符组成，占用空间大 |
| Snowflake算法 | 全局唯一，数字类型，存储成本低 | 机器规模大于1024台无法支持 |
雪花算法
snowflake是Twitter开源的分布式ID生成算法，结果是一个ong型的ID。
其核心思想是: 使用41bit作为毫秒数，10bit作为机器的ID(5个bit是数据中心，5个bit的机器ID)，12bt作为毫秒内的流水号(意味着每个节点在每毫秒可以产生4096个ID)，最后还有一个符号位，永远是0
设置雪花算法
实体类上添加注解@TableId(value = "id",type =IdType.ASSIGN_ID )
@TableId(value = "id",type =IdType.ASSIGN_ID )
private Long id;
此外，还可以指定机房id和机器id
mybatis-plus:
global-config:
# 机房id 0-31
datacenter-id: 1
# 机器id
workerId: 1
小结
数据库的索引是由id进行组织的一个b+树，而b+树这种数据结构，本身是一种有序的多叉树，使用自增id可以减少维护b+带来的性能开销；其次自增id通常使用个id类型的自增类型，而uuid是字符串，字符串所占用的内存空间比long大得多；同时在非聚簇索引每一个非叶子节点存储的就是主键，这也就意味着如果使用uuid每一页能存储的数量会变少，层高可能会变高，性能下降。
但是实际上我们的业务并没有特别高的并发量，并不会要求极致的性能，人员成本、开发周期等因素怎么也需要考虑；很多场景快速的当主键，也是不错的选择。
