数据库是否自增主键呢?
2024年07月05日
30
1 是否每张表都应该有自增主键?不一定自增主键可以加快行的插入速度,对于表的空间利用上有优势,碎片化不明显。但是对一些内容,如根据uid的查询非常频繁的,而且比较集中的,那如果不用自增主键,而是使用uid+id作为复合主键,那查询效率会上去,但插入和碎片化就会增加。但如果数据库的存储类型是ssd,那这个问题就不存在了。所以,大部分情况来看,表有自增主键是正确的。2 自增主键是否具有业务上的唯一性?不一定单表结构下,是的。多表情况下,不一定,需要一定的策略,如设定不同的后缀,相同的间隔等。
1 是否每张表都应该有自增主键?

不一定
自增主键可以加快行的插入速度,对于表的空间利用上有优势,碎片化不明显。

但是对一些内容,如根据uid的查询非常频繁的,而且比较集中的,那如果不用自增主键,而是使用uid+id作为复合主键,那查询效率会上去,但插入和碎片化就会增加。但如果数据库的存储类型是ssd,那这个问题就不存在了。

所以,大部分情况来看,表有自增主键是正确的。

2 自增主键是否具有业务上的唯一性?

不一定

单表结构下,是的。

多表情况下,不一定,需要一定的策略,如设定不同的后缀,相同的间隔等。

image.png

3 自增主键是否可以牵扯到业务?

不建议这样做。

如:表可以有自增主键,表内是具有唯一性的。在根据id查询和更新的时候,可以简化操作。但一般来说,和业务上存在关系,并且需要唯一性的时候,应该由业务自主去维护,如使用格式或算法,hash生成等方式。

4 业务维护的主键,怎样在多表的情况下保持唯一性?

维护自增键区间段,服务器每次取其中的一段,乐观锁更新。这个需要额外的表或策略来维护这个字段。

基于算法A,固定时间前缀,如:yyyyMMddHHmmss+表数mod值+随机数,通过位数的增加,来降低冲突的可能性。表字段存在唯一性约束(但有时候这个约束并不可靠)插入时若抛出重复字段值异常,则重新生成插入。

基于算法B,固定时间前缀,如:yyyyMMddHHmmss+固定位数碰撞自增值N+随机数。不需要通过位数的增加来降低冲突的可能性。当插入抛出重复字段值异常时,N++,重新插入,直到不再冲突为止。此后固定使用N作为中缀,并且N缓存于服务器,重启后继续使用此中缀。若出现重复异常,再次N++执行相同操作即可。N的mod值这些就不用故意提起啦。

基于中缀管理,即上报中缀到中心服务器,可以理解有地方缓存了服务器的id关系,动态分配中缀。

其他方法,还有很多,也没有用过,不赘述了。
算法B,简单,通信少,而且碰撞次数有限。算法A,存在无限次数的碰撞,尽管百分比非常非常低。但是在高并发的情况下,初始化的时候,算法B会比算法A来得更狂风暴雨一些。

区间段和中缀管理,都引入了中心节点的概念,依赖性比较强,但相对可靠,业界更为通用的实现方式。