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

但是对于一些内容，比如根据uid查询非常频繁集中，如果不需要添加自己的主键，而是使用uid ID作为复合键，查询效率会提高，但插入和碎片化会增加。但如果数据库的存储类型是ssd，那么这个问题就不存在了。

因此，在大多数情况下，表中有自增主键是正确的。

不一定

在单表结构下，是的。

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

不建议这样做。

例如，表可以有一个自添加的主键，表是独一无二的。在根据ID查询和更新时，操作可以简化。但一般来说，当与业务有关且需要独特性时，业务应独立维护，如使用格式或算法、hash生成等。

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

固定时间前缀基于算法A，如：yyyyMMddHHmmss 表数mod值 随机数，通过增加位数来减少冲突的可能性。如果在插入表字段时抛出重复字段值异常，则在插入表字段时有独特的限制（但有时限制不可靠）。

固定时间前缀基于算法B，如：yyyyMMddHHmmss 固定位数与自增值N相撞 随机数。冲突的可能性不需要通过增加位数来降低。重复字段值异常插入抛出时，N ，重新插入，直到不再发生冲突。此后固定使用N作为中缀，N缓存在服务器中，重启后继续使用中缀。如果出现重复异常，N将再次出现 可以执行相同的操作。N的mod值不需要故意提及。

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

还有很多其他的方法，还没用过，就不赘述了。
算法B简单，通信少，碰撞次数有限。算法A，有无限的碰撞次数，尽管百分比非常非常低。然而，在高并发性和初始化的情况下，算法B将比算法A更暴风雨。

区间段和中间装饰管理都引入了中心节点的概念，依赖性强，但相对可靠，实现行业更为普遍。

以上是数据库是否自增的关键？更多详细信息，请关注其他相关文章！