这篇文章主要讲解了“数据库主键相关问题有哪些”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“数据库主键相关问题有哪些”吧！
不一定自增主键可以加快行的插入速度，对于表的空间利用上有优势，碎片化不明显。
但是对一些内容，如根据uid的查询非常频繁的，而且比较集中的，那如果不用自增主键，而是使用uid+id作为复合主键，那查询效率会上去，但插入和碎片化就会增加。但如果数据库的存储类型是ssd，那这个问题就不存在了。
所以，大部分情况来看，表有自增主键是正确的。
不一定
单表结构下，是的。
多表情况下，不一定，需要一定的策略，如设定不同的后缀，相同的间隔等。
不建议这样做。
如：表可以有自增主键，表内是具有唯一性的。在根据id查询和更新的时候，可以简化操作。但一般来说，和业务上存在关系，并且需要唯一性的时候，应该由业务自主去维护，如使用格式或算法，hash生成等方式。
维护自增键区间段，服务器每次取其中的一段，乐观锁更新。这个需要额外的表或策略来维护这个字段。
基于算法A，固定时间前缀，如：yyyyMMddHHmmss+表数mod值+随机数，通过位数的增加，来降低冲突的可能性。表字段存在唯一性约束（但有时候这个约束并不可靠）插入时若抛出重复字段值异常，则重新生成插入。
基于算法B，固定时间前缀，如：yyyyMMddHHmmss+固定位数碰撞自增值N+随机数。不需要通过位数的增加来降低冲突的可能性。当插入抛出重复字段值异常时，N++，重新插入，直到不再冲突为止。此后固定使用N作为中缀，并且N缓存于服务器，重启后继续使用此中缀。若出现重复异常，再次N++执行相同操作即可。N的mod值这些就不用故意提起啦。
基于中缀管理，即上报中缀到中心服务器，可以理解有地方缓存了服务器的id关系，动态分配中缀。
其他方法，还有很多，也没有用过，不赘述了。算法B，简单，通信少，而且碰撞次数有限。算法A，存在无限次数的碰撞，尽管百分比非常非常低。但是在高并发的情况下，初始化的时候，算法B会比算法A来得更狂风暴雨一些。
区间段和中缀管理，都引入了中心节点的概念，依赖性比较强，但相对可靠，业界更为通用的实现方式。
感谢各位的阅读，以上就是“数据库主键相关问题有哪些”的内容了，经过本文的学习后，相信大家对数据库主键相关问题有哪些这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
