Mysql主键问题:类型问题int、bigint,主键选择问题：auto_increment自增、UUID、雪花算法构造全局自增id

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了Mysql主键问题:类型问题int、bigint,主键选择问题：auto_increment自增、UUID、雪花算法构造全局自增id，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含1408字，纯文字阅读大概需要3分钟。

内容图文

1.主键自增类型问题：int、bigint：

       有符号int最大约22亿，远大于一般业务需求了和MySQL单表所能支持的性能上限，其实主键达到20多亿时应该去考虑分库分表了，如果要加大预留量，可以把主键改为改为无符号int（int unsigned）上限约为42亿，这个预留量已经是非常的充足了；使用bigint，会占用更大的磁盘和内存空间，内存空间毕竟有限，无效的占用会导致更多的数据换入换出，额外增加了IO的压力，对性能是不利的。但也不是绝对的考虑到 int 自增存在有大量删除测试数据或删除历史过期数据后再新增初始值已不再是1,还有会存在自增步长非1情况，所有也并不能完全保证自增不会溢出。

总结：使用哪个类型做主键自增需要根据业务场景来考虑使用哪个类型了，比如传统项目数据量并不是很大时推荐自增主键使用int unsigned类型，互联网项目数据量很大时就需要使用bigint了否则真要溢出时再更改类型就很麻烦了。

 

2.主键选择问题：auto_increment自增、UUID、雪花算法构造全局自增id：

 

（1）单实例或者单节点组：

     经过500W、1000W的单机表测试，自增ID相对UUID来说，自增ID主键性能高于UUID，磁盘存储费用比UUID节省一半的钱。所以在单实例上或者单节点组上，使用自增ID作为首选主键。

 

（2）分布式架构场景：

      20个节点组下的小型规模的分布式场景，为了快速实现部署，可以采用多花存储费用、牺牲部分性能而使用UUID主键快速部署；

      20到200个节点组的中等规模的分布式场景，可以采用auto_increment自增ID+步长的较快速方案。

      200以上节点组的大数据下的分布式场景，可以借鉴类似twitter雪花算法构造的全局自增ID作为主键。

      参考： https://www.cnblogs.com/skying555/p/8647617.html

内容总结

以上是互联网集市为您收集整理的Mysql主键问题:类型问题int、bigint,主键选择问题：auto_increment自增、UUID、雪花算法构造全局自增id全部内容，希望文章能够帮你解决Mysql主键问题:类型问题int、bigint,主键选择问题：auto_increment自增、UUID、雪花算法构造全局自增id所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---