UPSERT并发竞争下的「幽灵ID」脏数据

前言

线上遇到一类隐蔽生产故障：程序运行无报错、事务正常提交，却源源不断产生僵尸脏数据。

当两个事务并发对同一业务单号执行UPSERT时，其中一个事务会被唯一索引排他记录锁阻塞；被阻塞的事务唤醒后，因唯一键冲突降级执行UPDATE，不会新增主表数据。

依托MyBatis-Plus雪花ID策略，实体提前在内存生成主键，若下游直接使用这个ID创建子记录，就会出现子表有数据、主表无匹配记录的「幽灵ID」脏数据。

环境说明

MySQL InnoDB，RC、RR隔离级别均会复现；

业务单号建立唯一索引；并发事务均使用UPSERT写入；

主键策略：使用 IdType.ASSIGN_ID （雪花算法）。

完整并发执行时序

1. 事务A、事务B同时处理同一业务单号 a ，执行UPSERT；

2. MP在SQL执行前，分别为两个实体在内存预生成独立雪花ID；

3. 事务A率先抢占唯一索引排他记录锁，执行SQL，事务尚未提交；

4. 事务B检测到锁冲突，进入阻塞等待。（备注：RC、RR隔离级别下，事务B均无法读取事务A未提交的数据，因此预先查询判断业务单号 a 是否存在无法规避该并发问题）；

5. 事务A执行commit，数据成功写入数据库；

6. 事务B被MySQL唤醒，再次校验唯一索引，发现单号 a 已存在；

7. 事务B进入UPDATE分支，仅更新已有记录，不会新增主表行。

幽灵ID产生核心原理

雪花ID由应用内存提前生成，和数据库执行结果无关。

即便UPSERT最终走入更新分支，没有插入新数据，实体对象依旧保留预先生成的雪花ID。

业务代码直接读取实体ID，用于新增明细、流水等子记录。

结果：事务B携带的雪花ID仅存在于JVM内存，数据库不存在该主键，也就是幽灵ID，最终滋生大量悬浮子表脏数据。

补充：IdType.AUTO 自增主键在UPSERT下的表现

自增主键行为和雪花ID有明显区别：

1. 常规写法：新建实体 id=null 。UPSERT进入UPDATE分支时，无法回调主键，实体ID维持null。只要代码增加ID非空判断，就能规避脏数据；

2. 危险写法：代码手动提前 setId() 设置占位ID。更新分支不会覆盖实体属性，占位ID保留，同样会生成幽灵ID。

整体来看，自增主键默认场景风险更低，但并非绝对安全。

生产级解决方案

1. UPSERT执行完成后，禁止直接使用实体内的主键。必须根据唯一键业务单号重新查询数据库，拿到真实持久化主键；

2. 校验UPSERT执行影响行数

int affectRows = mapper.upsert(entity); // 返回1：新增成功；返回2：冲突更新，禁止使用当前实体主键关联子数据

3. 针对业务唯一单号增加分布式锁，保证同一单号串行执行，从源头消除并发争抢；

4. 核心主数据业务不要无脑滥用UPSERT，可拆分新增、更新逻辑。

总结

同一唯一键并发UPSERT时，被锁阻塞的事务最终降级执行更新、不会新增主表记录。

雪花算法 IdType.ASSIGN_ID 预先在内存生成主键，极易诞生幽灵ID，是高频风险点；

自增主键 IdType.AUTO 仅在手动赋值实体ID的特殊场景下会踩坑。