mysql 5.7及更早版本中，子查询更新需用派生表或join绕过error 1093限制，因禁止同一表既查又改；postgresql和mysql 8.0+支持from或直接关联子查询，但须防null、多行及性能问题。
子查询更新必须用 JOIN 或 FROM 子句包裹
直接写 UPDATE table1 SET col = (SELECT col FROM table2 WHERE table2.id = table1.id) 在 MySQL 8.0+ 和 PostgreSQL 中能跑，但在 MySQL 5.7 及更早版本会报错 ERROR 1093 (HY000): You can't specify target table 'table1' for update in FROM clause。本质是 MySQL 禁止对同一张表既查又改——哪怕子查询逻辑上不冲突，解析器也直接拦截。
绕过方法只有一条：把子查询包进一层派生表（derived table），让优化器认为“这是另一张临时表”。
- MySQL 5.7 写法：
UPDATE table1 SET col = (SELECT t.col FROM (SELECT id, col FROM table2) AS t WHERE t.id = table1.id) - 更通用且易读的写法是改用
JOIN：UPDATE table1 INNER JOIN table2 ON table1.id = table2.id SET table1.col = table2.col - PostgreSQL 不限制子查询自引用，但用
FROM更安全：UPDATE table1 SET col = table2.col FROM table2 WHERE table1.id = table2.id
WHERE 条件漏写会导致全表误更新
子查询更新最危险的坑不是语法，而是逻辑失控。比如写成 UPDATE orders SET status = (SELECT status FROM users WHERE users.id = orders.user_id)，如果某个 orders.user_id 在 users 表里不存在，子查询返回 NULL，整张 orders 表对应字段全被设成 NULL——而且不会报错。
必须显式加 WHERE 确保关联存在：
- 用
EXISTS限定范围：UPDATE orders SET status = (SELECT status FROM users u WHERE u.id = orders.user_id) WHERE EXISTS (SELECT 1 FROM users u WHERE u.id = orders.user_id) - 或改用
JOIN，天然过滤无匹配行：UPDATE orders o JOIN users u ON o.user_id = u.id SET o.status = u.status - 注意：MySQL 的
JOIN UPDATE不支持LEFT JOIN更新左表未匹配行，想保留原值得用CASE WHEN判断
子查询返回多行会直接报错
Subquery returns more than 1 row 是常见错误。只要子查询没加 WHERE 或关联条件不唯一（比如用非主键字段连接），就可能命中。
检查三件事：
- 确认子查询里的关联字段在目标表中是唯一键（如
id、user_id），否则加LIMIT 1是掩耳盗铃，结果不可控 - 用
SELECT先验证子查询：SELECT order_id, (SELECT COUNT(*) FROM items i WHERE i.order_id = o.id) FROM orders o，看是否每行都只返回一个数 - 若业务上确实一对多（如取最新一条记录），必须用窗口函数或聚合：
(SELECT amount FROM items i WHERE i.order_id = o.id ORDER BY created_at DESC LIMIT 1)
性能差往往因为子查询没走索引
当子查询嵌套深或关联字段无索引时，更新可能从秒级变成分钟级。重点看执行计划里的 type 字段：
- 如果是
ALL或index，说明在全表扫描——立刻给WHERE条件字段加索引 - MySQL 中，
UPDATE ... JOIN比子查询快，因优化器能更好利用连接顺序和索引 - 大批量更新（>1万行）别用单条
UPDATE，拆成带LIMIT的循环，避免长事务锁表：UPDATE table1 SET col = ... WHERE id BETWEEN 1000 AND 2000
真正麻烦的是跨库或跨实例更新——SQL 子查询做不到，得靠应用层拉取再批量写入，这时候子查询思维反而会误导设计方向。
