前言线上遇到一类隐蔽生产故障程序运行无报错、事务正常提交却源源不断产生僵尸脏数据。当两个事务并发对同一业务单号执行UPSERT时其中一个事务会被唯一索引排他记录锁阻塞被阻塞的事务唤醒后因唯一键冲突降级执行UPDATE不会新增主表数据。依托MyBatis-Plus雪花ID策略实体提前在内存生成主键若下游直接使用这个ID创建子记录就会出现子表有数据、主表无匹配记录的「幽灵ID」脏数据。环境说明MySQL InnoDBRC、RR隔离级别均会复现业务单号建立唯一索引并发事务均使用UPSERT写入主键策略使用 IdType.ASSIGN_ID 雪花算法。完整并发执行时序1. 事务A、事务B同时处理同一业务单号 a 执行UPSERT2. MP在SQL执行前分别为两个实体在内存预生成独立雪花ID3. 事务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. 常规写法新建实体 idnull 。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的特殊场景下会踩坑。
)
