合并CustomerId并更新连续Version时触发唯一索引冲突，求解决方案

为什么你的UPDATE语句会违反唯一索引？ #

最核心的原因是数据库执行UPDATE时的中间状态冲突：
虽然标准SQL规定SET子句的多个列赋值是原子性的（同时生效），但部分数据库存储引擎（如InnoDB在某些场景下）的实际执行逻辑是逐行处理记录，并且可能先更新CustomerId列，再更新Version列。

当执行CustomerId = '4567', Version = Version + 2时，假设先把某条1234的记录的CustomerId改成4567，但此时Version还是原始值（比如1），这条记录就会和已存在的CustomerId=4567、Version=1的记录触发(CustomerId, Version)唯一索引冲突。

另外，你使用固定增量+2也存在隐患：如果在执行UPDATE前，有其他操作给4567新增了Version=3的记录，同样会导致冲突。

可行的解决方案 #

方案1：分两次更新，避免中间冲突

先把1234的Version临时调整到不会和4567冲突的范围，再修改CustomerId并修正Version：

-- 第一步：临时抬高1234的Version，避免和4567的现有Version冲突
UPDATE Table SET `Version` = `Version` + 100 WHERE CustomerId = '1234';

-- 第二步：修改CustomerId，并将Version调整为4567的连续版本
UPDATE Table 
SET CustomerId = '4567', 
    `Version` = `Version` - 100 + (SELECT MAX(`Version`) FROM Table WHERE CustomerId = '4567') 
WHERE CustomerId = '1234';

方案2：使用动态增量，基于4567的当前最大Version

用变量获取4567的最新最大Version，确保新增的Version完全连续且无冲突：

START TRANSACTION;

-- 获取4567的当前最大Version，若没有则设为0
SET @max_v = (SELECT COALESCE(MAX(`Version`), 0) FROM Table WHERE CustomerId = '4567');

-- 批量更新1234的记录，Version自动基于最大值顺延
UPDATE Table 
SET CustomerId = '4567', 
    `Version` = `Version` + @max_v 
WHERE CustomerId = '1234';

COMMIT;

方案3：控制更新顺序（MySQL专属）

通过ORDER BY让数据库先更新Version较大的记录，避免中间状态冲突：

UPDATE Table 
SET CustomerId = '4567', 
    `Version` = `Version` + 2 
WHERE CustomerId = '1234'
ORDER BY `Version` DESC;

（先更新Version=3的记录为5，再更新Version=2为4，最后更新Version=1为3，全程不会出现和4567现有Version重复的中间状态）

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