MySQL中UPDATE嵌套SELECT会导致性能雪崩，因其为每行重复执行子查询且常全表扫描；应改用JOIN并确保关联字段有索引，避免DEPENDENT SUBQUERY和锁等待激增。
UPDATE 里嵌套 SELECT 子查询更新另一张表，基本等于主动触发性能雪崩——不是语法错，是执行计划天然扛不住。
为什么子查询 UPDATE 总是全表扫描、锁表久
数据库对 UPDATE ... SET col = (SELECT ... FROM t2 WHERE t2.id = t1.ref_id) 这类写法，无法把子查询物化成一次结果再复用。它会为 t1 每一行都重新执行一遍子查询，且每次执行都可能走全表扫描（尤其当 t2.ref_id 没索引时）。你看到的 EXPLAIN 里反复出现 DEPENDENT SUBQUERY 或 Nested Loop + Materialize，就是这个信号。
- MySQL 5.7 及更早版本几乎从不自动转成半连接（semi-join），哪怕子查询只返回单值
- PostgreSQL 在小结果集上可能走 Hash Semi Join，但一旦子查询带聚合或条件复杂，就退回低效循环
- 锁粒度也变大：子查询反复执行 → 行锁/间隙锁反复申请 → 锁等待时间指数上升
MySQL 的 UPDATE JOIN 写法和常见报错点
MySQL 不支持标准 SQL 的 UPDATE ... FROM，必须用 UPDATE t1 JOIN t2 结构，但顺序和别名稍错就报错。
-
UPDATE后必须紧跟被更新表的别名（如UPDATE orders t1），不能写原表名再在SET里用别名 -
JOIN后只能空格加别名（JOIN customers t2），不能写AS t2 -
WHERE条件建议塞进ON里（如ON t1.cid = t2.id AND t2.is_vip = 1），否则容易漏过滤或引发笛卡尔积 - 示例正确写法：
UPDATE orders t1 JOIN customers t2 ON t1.customer_id = t2.id AND t2.is_vip = 1 SET t1.status = 'verified' WHERE t1.status = 'pending';
PostgreSQL 的 UPDATE FROM 为什么总提示 “table name specified more than once”
PostgreSQL 要求被更新表 **不能** 出现在 FROM 列表里，否则直接报错。它也不允许隐式关联，所有条件都得显式写出。
-
FROM后只写关联表（如customers c），千万别写orders t1或orders AS t1 -
WHERE中必须包含两表的等值关联（t1.customer_id = c.id），不能省略或挪到子句外 - 若
customers里一个id对应多行，PostgreSQL 会随机选一条更新——务必保证ON条件能唯一定位（比如加AND c.status = 'active'） - 示例正确写法：
UPDATE orders t1 SET status = 'verified' FROM customers c WHERE t1.customer_id = c.id AND c.is_vip = 1 AND t1.status = 'pending';
哪些情况 JOIN 更新反而更慢或结果出错
不是所有子查询都能无脑换 JOIN。以下三类最容易翻车：
- 子查询含
GROUP BY或聚合（如MAX(created_at)）：JOIN 无法直接替代，得先用 CTE 或派生表算好再关联 - 关联字段没索引：JOIN 加速的前提是
ON字段有索引，否则仍是嵌套循环全扫；检查EXPLAIN的key是否为NULL - 主表与子表是一对多，但业务只要“最新一条”：直接 JOIN 会放大行数，且结果不可控；此时该用窗口函数（
ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)）先筛再连
真正卡住人的，往往不是不会写 JOIN，而是忘了检查 ON 字段类型是否严格一致（比如一边是 VARCHAR(32)，另一边是 CHAR(32)）、忘了 NULL 值在 NOT IN 和 LEFT JOIN 中的行为差异、或者把本该下推到 ON 的过滤条件硬塞进了 WHERE 导致逻辑变更。
