Prisma更新两条Track记录交换索引时触发唯一约束报错求助

问题原因 #

你遇到的Unique constraint failed on the fields: ('room_id', 'index')错误，本质是并行更新时出现了中间状态的索引重复。比如交换两条Track的index（如A:1→2，B:2→1），并行执行更新时，其中一条先完成更新后，数据库中会短暂存在两个相同的index，触发唯一约束校验；多条记录重新排序时，中间步骤也会出现类似的重复冲突。

Prisma的批量更新（无论是Promise.all并行调用update，还是关联模型的tracks.update）都是并行执行更新操作，无法避免这种中间状态的冲突。

解决方案 #

方案1：针对少量记录交换（如两条）—— 临时值过渡 #

通过临时替换其中一条记录的index为全局唯一值（如负数，确保当前Room下无此索引），完成交换后再恢复，全程在事务中执行：

await this.db.$transaction(async (tx) => {
  // 获取两条待交换记录的当前index
  const trackA = await tx.track.findUnique({
    where: { roomId_trackId: { roomId: pin, trackId: trackIdA } },
    select: { index: true }
  });
  const trackB = await tx.track.findUnique({
    where: { roomId_trackId: { roomId: pin, trackId: trackIdB } },
    select: { index: true }
  });

  // 第一步：将trackA的index设为临时值（确保无冲突）
  await tx.track.update({
    where: { roomId_trackId: { roomId: pin, trackId: trackIdA } },
    data: { index: -1 }
  });

  // 第二步：更新trackB为trackA原来的index
  await tx.track.update({
    where: { roomId_trackId: { roomId: pin, trackId: trackIdB } },
    data: { index: trackA.index }
  });

  // 第三步：将trackA更新为trackB原来的index
  await tx.track.update({
    where: { roomId_trackId: { roomId: pin, trackId: trackIdA } },
    data: { index: trackB.index }
  });
});

方案2：针对多条记录重新排序—— 使用数据库原生SQL原子更新 #

利用数据库的原子更新能力，一次性完成所有索引的调整，避免中间状态冲突。以下以PostgreSQL为例，使用UPDATE ... FROM语法：

// 构造参数化查询，避免SQL注入
const params: (string | number)[] = [];
const valuePlaceholders = sorted.map((_, idx) => {
  // 依次传入roomId、trackId、目标index
  params.push(pin);
  params.push(sorted[idx].trackId);
  params.push(idx); // 这里的idx是目标新索引，根据你的业务逻辑调整
  return `($${3 * idx + 1}, $${3 * idx + 2}, $${3 * idx + 3})`;
}).join(',');

// 执行原生SQL更新
await this.db.$executeRaw(`
  UPDATE tracks
  SET index = new_index
  FROM (VALUES ${valuePlaceholders}) AS new_values(room_id, track_id, new_index)
  WHERE tracks.room_id = new_values.room_id
    AND tracks.track_id = new_values.track_id;
`, ...params);

如果是MySQL数据库，可以使用临时表或INSERT ... ON DUPLICATE KEY UPDATE的方式实现类似的原子更新逻辑，核心思路是让数据库一次性计算并应用所有新索引值，跳过中间状态的校验。

为什么你的原有方案失败？ #

• Promise.all并行执行更新：每个更新请求独立执行，数据库会依次处理，前一个更新完成后会改变数据库状态，导致后续更新触发唯一约束。
• 关联模型的tracks.update：Prisma内部会将其拆分为多个并行的更新操作，本质和第一种情况一致，无法避免中间冲突。

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