分库分表后如何处理id主键

分库分表后如何处理id主键

数据库自增 id

介绍

每次得到一个 id，都是往一个库的一个表里插入一条没什么业务含义的数据，然后获取一个数据库自增的一个 id。拿到这个 id 之后再往对应的分库分表里去写入。

• 优点：简单方便
• 缺点：无法应对高并发场景，单个数据库

适用场景

• 单库并发低
• 单库数据量小
• 并发低，数据量大

UUID

• 优点：本地生成，无需经过数据库
• 占用空间大，性能不够，无序，每次得到一个 id，都是往一个库的一个表里插入一条没什么业务含义的数据，然后获取一个数据库自增的一个 id。拿到这个 id 之后再往对应的分库分表里去写入。

适用场景：随机文件名，编号等，但不建议作为主键

数据库 sequence 或者表自增字段步长

sequence号是数据库系统按照一定规则自增的数字序列

• 优点：方便快捷
• 缺点：服务节点，步长固定，未来拓展时麻烦

系统时间戳

高并发时不考虑

snowflake 算法

64 位的 long 型的 id：

• 1 bit：不用，因为二进制里第一个bit为如果是 1，那么都是负数，但是我们生成的 id 都是正数，所以第一个bit统一都是 0。
• 41 bit：表示的是时间戳，单位是毫秒。41 bit 可以表示的数字多达 2^41 - 1，也就是可以标识 2^41 - 1 个毫秒值，69年。
• 10 bit：记录工作机器 id，代表的是这个服务最多可以部署在 2^10台机器上哪，也就是1024台机器。但是 10 bit 里 5 个 bit 代表机房 id，5 个 bit 代表机器 id。意思就是最多代表 2^5个机房（32个机房），每个机房里可以代表 2^5 个机器（32台机器）。
• 12 bit：这个是用来记录同一个毫秒内产生的不同 id，12 bit 可以代表的最大正整数是 2^12 - 1 = 4096，也就是说可以用这个 12 bit 代表的数字来区分同一个毫秒内的 4096 个不同的 id。