MySQL UPDATE中SET可安全引用同行列（如x=x+1），但WHERE和SET均基于更新前快照；多表UPDATE禁用ORDER BY/LIMIT，子查询需防全表扫描与多行报错。
MySQL 的 UPDATE 语句中，不能在 SET 子句里直接引用当前行被更新的字段做「计算依赖」，但可以安全引用同一行其他未被修改的字段；真正危险的是误以为 WHERE 或 JOIN 条件能「看到更新后的值」——它永远看到的是更新前的快照。
UPDATE 执行时 WHERE 和 SET 看到的都是旧值
很多人写 UPDATE t SET x = x + 1 WHERE x ，以为 WHERE 判断会随着 SET 逐行“动态变化”，其实不是。整个语句执行时，WHERE 条件基于事务开始时（或语句快照）的原始数据一次性筛选出所有匹配行，之后才对这些行批量执行 SET。这意味着：
- 即使你在 SET 中把
x改成 100，WHERE 仍用原来的x值判断是否入选 - 不存在“先改一行、再用新值决定下一行是否更新”的链式逻辑
- 这个行为和 SELECT 的执行顺序一致：
FROM → JOIN → ON → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT，UPDATE 的 WHERE 也属于“过滤阶段”，发生在任何赋值之前
自连接更新时 alias 的作用是隔离读取源
当你写 UPDATE employees AS e1 JOIN employees AS e2 ON e1.department_id = e2.department_id SET e1.salary = e1.salary * 1.1 WHERE e1.id != e2.id，关键点在于：e1 是目标表（要改的行），e2 是只读数据源。e2 的每一行都来自原表快照，不随 e1 的更新而变。
- e2 不是“更新中的 e1”，而是独立别名，指向同一张物理表的副本视图
- 这种写法本质是「用旧数据算新值」，不是「用刚更新的值去影响后续更新」
- 如果漏写
WHERE e1.id != e2.id，e1 可能和自身 join，导致 salary 被重复叠加（比如 100 → 110 → 121）
子查询更新需警惕相关子查询的重复求值
像 UPDATE users SET status = (SELECT 'vip' FROM orders WHERE orders.user_id = users.id AND amount > 1000 LIMIT 1) 这类写法，MySQL 会对每一行 users 执行一次子查询 —— 即使子查询结果为 NULL，也会完整扫描 orders 表（或走索引）。
- 性能陷阱：users 表有 10 万行，orders 表没建好
(user_id, amount)复合索引，就可能触发 10 万次全表扫描 - 语义陷阱：子查询返回多行会报错
Subquery returns more than 1 row，必须用LIMIT 1或聚合函数兜底 - 更稳写法是先用 JOIN 改写：
UPDATE users u JOIN orders o ON u.id = o.user_id AND o.amount > 1000 SET u.status = 'vip'
ORDER BY 和 LIMIT 在多表 UPDATE 中被禁用
单表 UPDATE 支持 ORDER BY 和 LIMIT，例如 UPDATE logs SET processed = 1 ORDER BY created_at LIMIT 100；但一旦用了 JOIN（哪怕只是自连接），这两个子句就失效，MySQL 会报错 You have an error in your SQL syntax。
- 原因：多表 UPDATE 的执行模型是基于笛卡尔积+条件过滤，无法定义跨表的排序依据
- 替代方案：用子查询先取 ID 列表，再套进主 UPDATE 的 WHERE 中，例如
WHERE id IN (SELECT id FROM ... ORDER BY ... LIMIT ...) - 注意：子查询里的 LIMIT 在 MySQL 8.0.19+ 才允许出现在 UPDATE 的 IN 子句中，低版本需用临时表中转
最易被忽略的一点：UPDATE 的原子性只保证单条语句内所有行要么全成功、要么全失败，但它不保证「按你期望的顺序执行」——尤其在并发场景下，两组 UPDATE 同时操作重叠行，最终结果取决于加锁顺序和事务隔离级别，而不是 SQL 文本里写的先后。
