如何在SQL UPDATE中引用修改前的原始值

SQL 标准本身是允许你在 UPDATE 的 SET 子句里直接引用被更新字段当前值的——也就是修改前的原始值，根本不需要额外搞子查询或临时变量。数据库执行时会先读取旧值，然后按表达式原子计算新值，整个过程一气呵成。很多初学者容易犯的错是：先跑个 SELECT 把旧值查出来，再手动拼个 UPDATE，不仅多了一次 IO，碰上并发还容易翻车。其实完全没必要，直接写字段名就行。

UPDATE 中直接用旧值参与计算是安全的

核心逻辑很简单：SET 子句里等号右边的字段名，指的就是更新前的值。数据库内部会先快照旧值，再计算结果写入。比如 UPDATE users SET balance = balance + 100 WHERE id = 123，等号右边的 balance 就是更新前的余额，加上 100 再写回去，全程原子操作，无锁冲突隐患。

常见误区是觉得必须用临时变量保存旧值，或者试图先查再更新。数据量小的时候看不出问题，一旦并发高了，查到的值可能已经不是最新了——更不用说多一次 IO 的损耗。其实，标准 SQL 早已内置了这种能力，直接写即可。

MySQL / PostgreSQL / SQL Server 都支持旧值直接运算

不同数据库在语法上基本一致，直接写字段名就行。不过有个小坑：字段名和表别名冲突时，部分数据库（比如旧版 MySQL）可能会报错。建议不要画蛇添足加别名前缀，直接写 SET col = col + 1 最稳。

• MySQL：UPDATE users SET balance = balance + 100 WHERE id = 123
• PostgreSQL：UPDATE orders SET total = total * 1.08 WHERE status = 'pending'
• SQL Server：UPDATE logs SET retry_count = retry_count + 1 WHERE last_error IS NOT NULL

如果非要用别名，比如 UPDATE t SET t.col = t.col + 1，虽然多数现代数据库能处理，但为了兼容性和少踩坑，还是省略为妙。

不能在 WHERE 或 JOIN 条件里“同时依赖”新旧值

WHERE 子句在 UPDATE 执行前就完成了求值，它看到的是原始行数据。所以你试图在 WHERE 里用刚被 SET 修改后的字段做判断——比如 SET x = x + 1 WHERE x + 1 > 10——逻辑上没问题，因为 x + 1 用的还是旧值来计算。真正危险的是误以为 WHERE 能看到“即将写入的新值”，那是不可能的。

• 交换两列：UPDATE t SET a = b, b = a WHERE a > b 并不能实现交换——因为两字段同时基于旧值赋值，不是原子交换。正确做法是直接用单条 UPDATE t SET a = b, b = a，多数现代数据库（PostgreSQL、MySQL 8.0+、SQL Server）都支持，且语义明确。
• 禁止引用别名：SET 子句中定义的别名不能在 WHERE 里引用，比如 UPDATE t SET x = y * 2 AS new_x WHERE new_x > 10 是不合法的，标准 SQL 不允许。

触发器或 RETURNING 是获取旧值的补充手段

如果业务需要在更新后立刻拿到旧值——比如记录审计日志或发通知——UPDATE 本身不返回旧值，得靠扩展机制。

• PostgreSQL：用 RETURNING OLD.*，例如 UPDATE users SET email = 'new@ex.com' WHERE id = 42 RETURNING OLD.email, OLD.created_at
• MySQL：没有原生 RETURNING，需要靠 SELECT ... FOR UPDATE 加事务封装，但要注意锁粒度和死锁风险。
• SQL Server：用 OUTPUT DELETED.*，例如 UPDATE users SET name = 'Alice' OUTPUT DELETED.name WHERE id = 42
• 触发器：PG 里通过 OLD，SQL Server 用 DELETED 访问旧值。不过触发器性能开销大，非必要不建议启用。

最后提醒一点：即使你只改一个字段，整行锁仍可能被持有更久——尤其在大表上用 WHERE 匹配大量行时，旧值计算本身虽快，但锁竞争才是真正的瓶颈。设计更新逻辑时，尽量缩小更新范围，避免长事务锁住过多行。