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