mysql使用什么字段做主键，是重点考虑两方面：业务场景和效率问题。在满足业务场景的前提下，使用自增序列做主键是最优选择。原因如下：
1.自增主键节省存储空间。
2.innodb的索引特性导致了自增id做主键是效率最好的
与UUID主键对比：
在500W记录表的测试下：
（1） 普通单条或者20条左右的记录检索，uuid为主键的相差不大几乎效率相同；
（2） 但是范围查询特别是上百成千条的记录查询，自增id的效率要大于uuid；
（3） 在范围查询做统计汇总的时候，自增id的效率要大于uuid；
（4） 在存储上面，自增id所占的存储空间是uuid的1/2；
（5） 在备份恢复上，自增ID主键稍微优于UUID。
在1000W记录表的测试下：
（1）普通单条或者20条左右的记录检索，自增主键效率是uuid主键的2到3倍；
（2）但是范围查询特别是上百成千条的记录查询，自增id的效率要大于uuid；
（3）在范围查询做统计汇总的时候，自增id主键的效率是uuid主键1.5到2倍；
（4）在存储上面，自增id所占的存储空间是uuid的1/2；
（5）在写入上面，自增ID主键的效率是UUID主键的3到10倍，相差比较明显，特别是update小范围之内的数据上面。
（6）在备份恢复上，自增ID主键稍微优于UUID。
对于InnoDB这种聚集主键类型的引擎来说，数据会按照主键进行排序，由于UUID的无序性，InnoDB会产生巨大的IO压力，而且由于索引和数据存储在一起，字符串做主键会造成存储空间增大一倍。
在存储和检索的时候，innodb会对主键进行物理排序，这对auto_increment_int是个好消息，因为后一次插入的主键位置总是在最后。但是对uuid来说，这却是个坏消息，因为uuid是杂乱无章的，每次插入的主键位置是不确定的，可能在开头，也可能在中间，在进行主键物理排序的时候，势必会造成大量的 IO操作影响效率，在数据量不停增长的时候，特别是数据量上了千万记录的时候，读写性能下降的非常厉害。
总结：
（1）单实例或者单节点组：
经过500W、1000W的单机表测试，自增ID相对UUID来说，自增ID主键性能高于UUID，磁盘存储费用比UUID节省一半的钱。所以在单实例上或者单节点组上，使用自增ID作为首选主键。
（2）分布式架构场景：
20个节点组下的小型规模的分布式场景，为了快速实现部署，可以采用多花存储费用、牺牲部分性能而使用UUID主键快速部署；
20到200个节点组的中等规模的分布式场景，可以采用自增ID+步长的较快速方案。
200以上节点组的大数据下的分布式场景，可以借鉴类似twitter雪花算法构造的全局自增ID作为主键
网友评论