数据库的唯一标示符（ID）的选择

背景：数年的工作中，已经设计了很多系统或产品的数据库，有单机的、有局域网环境下的、也有互联网环境下的，对于不同的环境，设计考虑都有所不同。即使对于相同

背景：数年的工作中，已经设计了很多系统或产品的数据库，有单机的、有局域网环境下的、也有互联网环境下的，对于不同的环境，设计考虑都有所不同。即使对于相同的环境，，也会因为业务或者数据量的不同而有不同的设计。近期，又要设计一款互联网产品的数据库（MySQL服务）。经过之前的积累，在表的ID设计这个环节就进行了大量的分析、比较、学习，对ID的设计也有了更系统和深刻的认知，把自己学习实践到的知识总结下来，分享给大家。

主键id的选择

对于关系数据库来说，设计每个表的第一步都会确定其主键，主键就是ID。在“常识”之中，int型的自增id，字符串类型的uuid，其他与业务相关的唯一键…都是我们作为主键的选择。那么是不是说在一张表中只要能保证值唯一的属性列都可以做为主键或者更合适做主键呢？

那我们首先清晰几个概念：

所以说明逻辑主键和业务主键的选择并不是拍脑瓜的结果，而是根据不同的应用场景、不同的需求决策的结果。

如果我们使用整数类型的自增id作为主键又会面临什么问题呢？
对于数据量非常大的表后期往往会涉及到水平分表的需求，这时这个自增主键会成为阻碍。（其实关于这种情况也会有解决方案，请参见文章《又拍网架构中的分库设计》

ID数据类型的选择

我们再换一个角度考虑主键的选择：数据类型。

整数类型：
整数类型往往是id列最好的选择，因为效率最高并且可以使用数据库的自增主键。

字符串类型
字符串类型相比整数类型肯定更消耗空间，也会比整数类型操作慢。我主要使用的是Mysql，关于这个话题的解释建议看《高性能MySQL》第三版 P125。

我采用的方案（MySQL）：使用自增id作为主键，以此来应对插入效率问题；采用uuid做逻辑id，拥有了逻辑主键的诸多好处，而且可以用来应对之后的水平分表。

本文出自 “永远的朋友” 博客，请务必保留此出处