SQL实现表中两列数据互换方法：中间变量与异或运算

说到数据表里两列值互换，很多人的第一反应是：“得找个临时变量吧？” 或者琢磨着用异或运算这种“奇技淫巧”。其实，这事儿在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的抽象层，以保证操作的原子性和正确性。