关于数据库自增主键的几个问题

1 是否每张表都应该有自增主键？

不必定

自增主键能够加快行的插入速度，对于表的空间利用上有优点，碎片化不明显。

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

因此，大部分状况来看，表有自增主键是正确的。

2 自增主键是否具备业务上的惟一性？

不必定

单表结构下，是的。

多表状况下，不必定，须要必定的策略，如设定不一样的后缀，相同的间隔等。

3 自增主键是否能够牵扯到业务？

不建议这样作。

如：表能够有自增主键，表内是具备惟一性的。在根据id查询和更新的时候，能够简化操做。但通常来讲，和业务上存在关系，而且须要惟一性的时候，应该由业务自主去维护，如使用格式或算法，hash生成等方式。

4 业务维护的主键，怎样在多表的状况下保持惟一性？

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

基于算法A，固定时间前缀，如：yyyyMMddHHmmss+表数mod值+随机数，经过位数的增长，来下降冲突的可能性。表字段存在惟一性约束（但有时候这个约束并不可靠）插入时若抛出重复字段值异常，则从新生成插入。

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

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

其余方法，还有不少，也没有用过，不赘述了。

 

算法B，简单，通讯少，并且碰撞次数有限。算法A，存在无限次数的碰撞，尽管百分比很是很是低。可是在高并发的状况下，初始化的时候，算法B会比算法A来得更暴风骤雨一些。

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