说到数据表里两列值互换，很多人的第一反应是：“得找个临时变量吧？” 或者琢磨着用异或运算这种“奇技淫巧”。其实，这事儿在SQL里，比你想的要简单直接得多。
直接用UPDATE交换，会出错吗？
放心，不会出错，而且这才是标准做法。SQL的UPDATE语句在设计上就考虑到了这种场景。当你写下SET a = b, b = a时，数据库引擎会基于语句执行前的“旧值快照”来计算右侧的值。也就是说，它先记住a和b原来的值，然后再进行赋值，因此交换是原子性且安全的。常见的误区是，把编程思维带进来，总想手动找个“中间变量”，结果画蛇添足，可能还会引发不必要的锁或事务开销。
主流数据库里怎么写？
语法其实非常统一。在MySQL、PostgreSQL、SQL Server、SQLite等主流关系型数据库中，你都可以这样写：
UPDATE users SET name = nickname, nickname = name;
这里有几个关键点：首先，name和nickname必须是同一张表的列；其次，即使右侧包含计算（比如col1 = col2 + 1），计算所用的也始终是更新前的旧值，不会因为同一条语句里左侧的赋值而受影响。这条语句在MySQL 5.7+、PostgreSQL 9.0+及以后版本都是完全有效的。
异或运算（XOR）是条歧路
你可能在网上见过用异或运算交换数值的“炫技”代码。但在数据库领域，这基本是条歧路。原因有三：
- 类型限制：XOR本质是位运算，只适用于整数等数值类型。对于字符串、日期、JSON等常见类型，它完全无能为力。
- NULL值陷阱：SQL中，任何值与
NULL进行位运算，结果都是NULL。如果待交换的列中存在NULL，数据会静默丢失，这是灾难性的。 - 可读性与兼容性：XOR不是SQL标准函数，实现各异（MySQL用
^，PostgreSQL用bitwise_xor()）。其可读性远不如直接的赋值语句，对后续维护极不友好。
所以，记住这个结论：用SET a = b, b = a，忘掉XOR。
条件交换与复杂场景处理
如果只想对部分行进行交换，直接加上WHERE子句即可，交换逻辑本身不变：
UPDATE products SET price = discount_price, discount_price = price WHERE status = 'on_sale';
这里的WHERE会在更新前过滤行，被选中的每一行内部依然安全地执行旧值交换。
那如果需求更复杂呢？比如，想对不同行实施不同的列值转移规则（而非简单的两两互换）。这时，你需要的是CASE表达式进行条件赋值，这已经超出了“交换”的范畴，但更贴近真实业务：
UPDATE orders SET status = CASE WHEN id % 2 = 0 THEN 'shipped' ELSE 'pending' END, updated_at = CASE WHEN id % 2 = 0 THEN created_at ELSE updated_at END;
最后，还有一个实战中容易踩的坑：某些对象关系映射（ORM）工具，出于其设计模式，可能不支持在单条语句中执行这种多列交换。它们可能会将其拆分成两条顺序执行的更新语句，从而导致第二句读到的是第一句更新后的“脏”值。如果你在使用诸如Django ORM等框架，遇到这种情况，最稳妥的方式是直接执行原生SQL语句，绕过ORM的抽象层，以保证操作的原子性和正确性。
