先看一个最常见的场景：有一张商品表 product，里面保存了旧价格 old_price 和新价格 new_price，某次数据订正时想把两列互换。开发者通常会顺手写下 UPDATE product SET old_price=new_price, new_price=old_price;。如果当前行的旧价格是 100，新价格是 200，直觉上结果应该是旧价格变为 200，新价格变为 100。然而在 MySQL 中执行这段语句后，查询结果很可能是两列都变成了 200。
这个现象并不是 SQL 语法写错了，而是和数据库引擎对 UPDATE 语句中 SET 子句的赋值顺序处理有关。要理解原因，需要区分两个概念：一个是 SQL 标准规定的理想语义，另一个是具体数据库实现时的执行规则。搞清楚这些后，才能知道哪些数据库可以直接交换列值，哪些数据库需要改写 SQL。
一、MySQL 单表 UPDATE 的赋值顺序
MySQL 官方文档对单表 UPDATE 的行为描述得很清楚：赋值通常按从左到右的顺序进行。也就是说，在 SET a=b, b=a 中，MySQL 先执行 a=b，再执行 b=a。当执行第二个赋值时，语句读取到的 a 已经不是原始值，而是第一个赋值刚刚写入的新值。
举个具体例子，先创建一张测试表并插入一行数据：
CREATE TABLE demo_swap ( id INT PRIMARY KEY, a INT NOT NULL, b INT NOT NULL ); INSERT INTO demo_swap (id, a, b) VALUES (1, 10, 20);
接下来执行交换语句：
UPDATE demo_swap
SET a = b,
b = a
WHERE id = 1;
在 MySQL 中，第一项 a=b 读取原始 b 的值 20 写入 a，此时 a 变成 20。第二项 b=a 读取的是已经更新过的 a，也就是 20，因此 b 也变成 20。最终该行的 a 和 b 都是 20，并没有完成交换。
如果把赋值顺序反过来写：SET b=a, a=b，第一项先让 b 变成原始 a 的值 10，第二项再读取更新后的 b 值 10 写入 a，结果两列都是 10。由此可见，无论 A、B 谁先出现，只要后面的赋值引用了前面刚修改过的列，就会丢失原始数据。
二、SQL 标准与其他数据库的差异
与 MySQL 的单表行为不同，SQL 标准通常要求 UPDATE 语句中所有右侧表达式都基于该行的更新前快照进行计算。这意味着 SET a=b, b=a 会同时读取原始 a 和原始 b，所以两个赋值完成后，a 和 b 恰好互换。
PostgreSQL 是遵循这种语义的典型代表。执行上面的例子，PostgreSQL 会返回 a=20、b=10。SQL Server 的更新也采用类似机制，右侧读取的是更新前的值。Oracle 和 SQLite 同样使用旧行快照，因此两条赋值互不影响，可以完成交换。
可以做一个简单对比：
| 数据库 | SET a=b, b=a 的结果 | 赋值语义 |
|---|---|---|
| MySQL 单表 UPDATE | a 与 b 都变成原 b | 从左到右，后项可看到前项修改 |
| PostgreSQL | a 与 b 交换 | 基于旧行快照 |
| SQL Server | a 与 b 交换 | 基于旧行快照 |
| Oracle | a 与 b 交换 | 基于旧行快照 |
| SQLite | a 与 b 交换 | 基于旧行快照 |
正因为 MySQL 的这一实现差异，很多从 PostgreSQL 或 SQL Server 迁移到 MySQL 的项目会踩到列交换失败的问题。开发人员不能只依赖 SQL 标准来推断结果，还要结合当前数据库版本的文档进行验证。尤其是 MySQL 多表 UPDATE 的赋值顺序没有保证，更不能写出依赖前序赋值结果的语句。
三、在 MySQL 中可靠交换两列值的方法
既然 MySQL 单表 UPDATE 无法通过简单的一条 SET a=b, b=a 交换，就需要换一种思路。核心目标是让两个原始值在更新前被保存下来，避免第二个赋值读取到第一个赋值修改后的结果。常见做法有三种：增加临时列、使用用户变量、拆分为多个更新语句。
第一种是增加临时列。如果表结构允许，可以添加一列 tmp，执行 UPDATE demo_swap SET tmp=a, a=b, b=tmp;。这里 tmp=a 先保存原始 a 值，接着 a=b 读取原始 b 值，最后 b=tmp 读取临时列中的原始 a 值。由于每个赋值引用的列都没有在前序赋值中被修改，整个交换可以一次完成。示例：
ALTER TABLE demo_swap ADD COLUMN tmp INT NULL;
UPDATE demo_swap
SET tmp = a,
a = b,
b = tmp;
ALTER TABLE demo_swap DROP COLUMN tmp;
第二种是使用 MySQL 用户变量保存旧值。需要注意变量赋值的求值顺序也非常容易出错，建议先在 SELECT 中取出旧值，再用变量更新。例如：
SELECT @old_a := a, @old_b := b
FROM demo_swap
WHERE id = 1;
UPDATE demo_swap
SET a = @old_b,
b = @old_a
WHERE id = 1;
这段代码先锁定原始值，再执行更新，逻辑清晰，也不依赖 SET 子句内部的求值顺序。不过用户变量存在会话级作用域，若连接复用或批量处理多行时需要格外小心，否则容易把上一行的变量值带到下一行，造成数据错乱。
第三种是拆分为多条 UPDATE，并借助一个不会被业务使用的临时值。比如先把原 a 保存到另一个列，或者使用事务配合 SELECT FOR UPDATE 锁定行，再分别更新 a 和 b。对于 MySQL 8.0，也可以先创建派生表或临时表保存旧值，再回填。总之只要保证旧值有地方暂存，交换就是安全的。
四、避免依赖赋值顺序的工程实践
即使当前数据库支持旧行快照，也不建议在业务代码里写大量依赖 SET 子句求值顺序的更新语句。一个原因是不同数据库行为不一致，迁移成本高；另一个原因是 MySQL 多表更新、子查询更新等场景下，优化器可能选择不同的执行路径，赋值顺序无法稳定预测。
如果确实需要交换列值，可以封装成一个明确的过程：先查询并核对原始值，再使用临时列或临时表完成更新，最后验证结果。这样即使数据库版本升级或执行计划改变，程序也不会因为赋值顺序的隐式约定而出现错误。
对于数据量较大的表，交换两列通常需要扫描整张表或部分行。临时列方案会触发表结构变更和索引维护，可能比一条 UPDATE 慢很多。此时可以评估直接使用 ALTER TABLE ... CHANGE 或通过数据迁移工具来处理，但这种操作涉及元数据调整，需要根据业务窗口决定。
最后再强调一次排查思路：当 UPDATE 执行结果与预期不符时，不要只盯着 WHERE 条件，还要检查 SET 子句内部是否存在列引用。尤其是 a=b,b=a、a=a+1,b=a 这类前后依赖的写法，在 MySQL 中很容易产生难以察觉的数据错误。理解了字段赋值顺序，才能写出跨数据库更稳妥的更新语句。
SQL UPDATE字段赋值顺序数据交换修改时间：2026-08-30 20:11:56