Java中主键自增的机制 主键用自增还是uuid

数据库的主键选啥好

其实针对使用自增长还是UUID，大家讨论最多的就是速度和存储空间，这里我加入了安全性和分布式，具体对比如下：

使用自增长做主键的优点：1、很小的数据存储空间2、性能最好3、容易记忆使用自增长做主键的缺点：1、如果存在大量的数据，可能会超出自增长的取值范围2、很难（并不是不能）处理分布式存储的数据表，尤其是需要合并表的情况下3、安全性低，因为是有规律的，容易被非法获取数据使用GUID做主键的优点：1、它是独一无二的，出现重复的机会少2、适合大量数据中的插入和更新操作，尤其是在高并发和分布式环境下3、跨服务器数据合并非常方便4、安全性较高使用GUID做主键的缺点：1、存储空间大（16 byte），因此它将会占用更多的磁盘空间2、会降低性能3、很难记忆

结合每个项目的实际应用，我们应该怎么选择呢？如下：

1、项目是单机版的，并且数据量比较大（百万级）时，用自增长的，此时最好能考虑下安全性，做些安全措施。2、项目是单机版的，并且数据量没那么大，对速度和存储要求不高时，用UUID。3、项目是分布式的，那么首选UUID，分布式一般对速度和存储要求不高。4、项目是分布式的，并且数据量达到千万级别可更高时，对速度和存储有要求时，可以用自增长。

现在有人就会问了，为什么不直接用第4种方案，它满足前面三种方案的所有要求？就是因为在用自增长时分布式处理会很复杂（具体方案可以百度），在资源有限的情况可以采用前面三种简单的实现方案。

那么，为什么一定要使用自增长或UUID作为数据库主键呢？有没有更好的解决方案呢？肯定有：snowflake

其实大部分项目可以使用twitter的snowflake来生成主键，snowflake生成的主键就是介于自增长和UUID之间的一种主键（存储空间小、速度快、分布式、时间序列）。据说snowflake每秒能够产生26万个ID，最多可以部署在1024个节点上，研发团队可以将snowflake作为底层的数据库主键工具类供团队成员使用。

我自己的观点是：对于项目中涉及到的业务名称表的主键用UUID，而业务与业务之间的关系表的主键用自增；

在全栈的道路上，积极向上、成熟稳重、谦虚好学、怀着炽热的心向前方的走得更远。