如何选择数据库ID字段类型？UUID or 雪花算法 or 自增整型?

一、UUID:

标准的UUID格式是(8-4-4-4-12),共36个字符.

优点：

①能够保证独立性，字符串类型对数值型也能兼容不重复，程序可以在不同的数据库间迁移
②保证生成的ID不仅是表独立的，而且是库独立的
③可以用32进制对原先进行缩小存放

缺点：

UUID占用内存空间大，每次生成的都是随机的串，增删改会导致索引B+树重建索引定位更慢，不易排序(常见缩短UUID长度的方式是(1.省略"-";2.扩大每位的进制数))

二、雪花算法:

组成结构：

优点：

①自增Long型(趋势递增，递增但不连续)的ID，固定19位10进制(或者64位2进制)，耗费空间比UUID小，走索引速度更快，对于排序有更好的性能
②对同一公司的统一算法计量的设备能够唯一表示，对分布式是友好的，且对数据库索引是友好的

缺点：

①依赖于机器时钟，如果机器时钟回拨有可能出现重复ID。
②由于雪花算法生成的ID是19位数字，传递给前端会出现精度丢失(前端会接收一个17位有效数字的科学计数法数字)
2.1 解决方法一：通过配置将数字都序列化成字符串的配置解决雪花算法精度丢失

spring.jackson.generator.write-numbers-as-strings= true

2.2 解决方法二：使用配置类或者注解，改变序列化过程（加在pojo的ID字段上）

//序列化时将该字段序列化成字符串
@JsonSerialize(using = ToStringSerializer.class)
private Long id;

三、整型自增ID:

优点：

自增Long类型的主键可以主键自增，数字类型占用空间小，走索引速度更快，对于排序有更好的性能

缺点：

①若需要手动插入，或者从其他系统导入带有ID的数据，这些数据的id和原来数据的id容易造成冲突，若其他系统的ID不是数值型的，则同步数据更加痛苦
②从1自增上去的ID，容易被猜测进行数据窃取等安全问题
③对分布式很不友好，即使用分段生成的ID(比如定义5千万后的ID给二数据库)也有可能之前一段的超额导致重复的问题；若是采用取余分布ID(3个数据库集群，就对三取余，相同余数的位于一个数据库)的策略，扩容后该如何对之前的数据进行处理又是难题。