Prisma事务中MySQL自增ID分配不一致问题及解决咨询

问题根源 #

你当前的事务逻辑是先创建User再创建Account：

await prisma.$transaction(async (tx) => {
    const user = await tx.user.create({
        data: { ... },
    })
    await tx.account.create({
        data: { ... },
    });
});

当事务在Account创建环节失败回滚时，User的插入操作虽被撤销，但数据库的自增ID计数器已经往前跳了一位，导致User表出现ID断档；而Account还没执行到插入步骤，自增ID不会被消耗，所以断档数量少。

可行的解决方案 #

• 调换事务内操作顺序：把Account的创建放在User前面。这样如果后续User创建失败回滚，被消耗自增ID的是Account而非User，将断档转移到对ID连续性要求更低的表上，直接解决User表断档多的问题。
• 改用应用层生成唯一ID：放弃数据库自增ID，改用UUID、雪花算法等应用层生成的唯一标识作为主键。这类ID由应用在插入前生成，只有事务成功提交时才会写入数据库，事务失败则ID不会被占用，从根源上避免断档。
• 提前做全量校验：在进入事务之前，完成所有业务规则校验、参数合法性检查（比如用户手机号是否重复、账号格式是否合规）。尽量避免进入事务后才发现数据问题导致回滚，减少自增ID的无效消耗。
• 调整数据库自增锁策略（仅针对MySQL）：如果使用MySQL，可尝试将innodb_autoinc_lock_mode设置为0（传统锁模式），但这会降低并发插入性能，仅适合对ID连续性要求极高且并发量不大的场景，需谨慎使用。

内容的提问来源于stack exchange，提问作者oyram1007