其实针对使用自增长还是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，而业务与业务之间的关系表的主键用自增；