解决 MyBatis-Plus 中 ID 自增问题

MyBatis-Plus 中自动生成的 ID 过长，可能导致以下问题的出现：

• 由于属性的 ID 是由 mp 内部的 UUID 生成，比如使用 Integer类型 将存不进去
• 当后端传入 mp 雪花算法自动生成的 ID 时，前端接收的时候可能会导致精度的损失

问题一：由于属性的 ID 是由 mp 内部的 UUID 生成，比如使用 Integer类型 将存不进去

报错信息如下所示：

ested exception is org.apache.ibatis.reflection.ReflectionException: Could not set property 'id' of 'class com.xxx' with value '111042370348747XXXX Cause: java.lang.IllegalArgumentException: java.lang.ClassCastException@14041406

 

解决方法：

将 ID 字段类型改为 long，这样就能保证有足够位数放入生成的 ID

问题二：当后端传入 mp 雪花算法自动生成的 ID 时，前端接收的时候可能会导致精度的损失

解决方法：

第一步：

首先在对应的类的主键属性上，增加以下代码配置

@TableId(value = "id",type = IdType.AUTO)
    private Long id;

type 属性中，其他类型如下： 

• AUTO：AUTO(0, “数据库ID自增”),

• INPUT：INPUT(1, “用户输入ID”),

• ID_WORKER：ID_WORKER(2, “全局唯一ID”),

• UUID：UUID(3, “全局唯一ID”),

• NONE：NONE(4, “该类型为未设置主键类型”),

• ID_WORKER_STR：ID_WORKER_STR(5, “字符串全局唯一ID”);

第二步：

将之前的被自增长的ID数据删除

第三步：

在需要解决 mp 自增长的表中，执行以下语句

ALTER TABLE table_name AUTO_INCREMENT = value;

其中， table_name 是对应的表名，value 是你需要进行自增的 ID 值

比如：value 赋值为 2，则 mp 下次生成的 ID 则为2，即从 2 开始

自增主键与 UUID 的优缺点

自增主键：

这种方式是使用数据库提供的自增数值型字段作为自增主键

优点：

1. 数据库自动编号，速度快，而且是增量增长，按顺序存放，对于检索非常有利
2. 数字型，占用空间小，易排序，在程序中传递也方便
3. 如果通过非系统增加记录时，可以不用指定该字段，不用担心主键重复问题

缺点 ：

1. 因为自动增长，在手动要插入指定ID的记录时会显得麻烦，尤其是当系统与其它系统集成时，需要数据导入时，很难保证原系统的ID不发生主键冲突（前提是老系统也是数字型的）
2. 如果经常有合并表的操作，就可能会出现主键重复的情况很难处理分布式存储的数据表
3. 数据量特别大时，会导致查询数据库操作变慢；此时需要进行数据库的水平拆分，划分到不同的数据库中，那么当添加数据时，每个表都会自增长，导致主键冲突

UUID：

优点：

能够保证独立性，程序可以在不同的数据库间迁移，效果不受影响；保证生成的ID不仅是表独立的，而且是库独立的，这点在你想切分数据库的时候尤为重要

缺点：

1. 比较占地方，和INT类型相比，存储一个UUID要花费更多的空间
2. 使用UUID后，URL显得冗长，不够友好
3. Join 操作性能比 int 要低
4. UUID做主键将会添加到表上的其他索引中，因此会降低性能