MySQL 8.0+ 允许部分子查询更新但仍有1093错误风险，旧版必须用派生表或JOIN；JOIN更安全通用，子查询须为标量且性能差，WHERE位置影响结果与NULL赋值。
UPDATE 里用子查询更新字段，MySQL 8.0+ 和旧版本写法不同
MySQL 5.7 及更早版本不支持在 UPDATE 的 SET 子句中直接引用被更新的表（会报错 ERROR 1093: You can't specify target table 'xxx' for update in FROM clause），而 MySQL 8.0+ 允许部分场景下直接嵌套，但仍有约束。
- 旧版必须绕过：用派生表（
SELECT套一层FROM）或JOIN替代子查询 - 新版虽支持，但若子查询里还涉及同一张表，依然会触发 1093 错误——不是版本高就能随便写
- PostgreSQL / SQL Server 对这种写法更宽松，但语法细节不同，不能直接移植
用 JOIN 实现安全、跨表匹配更新（最通用方案）
比子查询更稳定，兼容所有主流数据库，语义清晰，执行计划也更容易优化。
- 把要更新的目标表和提供数据的源表（或子查询结果）用
JOIN连接，ON条件对齐关联字段 -
SET后面只写目标表的列，右边可直接引用源表字段，无需嵌套SELECT - 务必加
WHERE过滤，否则可能误更新整张表；如果源表有重复关联键，可能引发多对一更新，结果不可控
示例（更新 orders 表的 customer_name 字段，从 customers 表取值）：
UPDATE orders o JOIN customers c ON o.customer_id = c.id SET o.customer_name = c.name WHERE o.status = 'pending';
子查询写法踩坑：标量子查询 vs 多行子查询
子查询必须返回**单个值**（标量），否则会报 ERROR 1242: Subquery returns more than 1 row。这不是警告，是硬性错误。
- 确保子查询的
WHERE条件足够严格，能唯一确定一行，比如用主键或带LIMIT 1（但LIMIT不推荐，掩盖逻辑缺陷） - 别在子查询里漏写关联条件，例如忘记写
WHERE t2.order_id = t1.id，导致变成全表扫描+随机取值 - 子查询性能差：每更新一行，子查询都执行一次，大数据量时极慢；
JOIN是一次性关联，效率高得多
正确示例（安全的标量子查询）：
UPDATE orders SET customer_name = ( SELECT name FROM customers WHERE id = orders.customer_id ) WHERE customer_id IS NOT NULL;
WHERE 条件写在子查询外还是内？影响结果和性能
写错位置会导致漏更新、重复更新，甚至锁住不该锁的行。
- 过滤「要更新哪些行」，写在
UPDATE主句的WHERE—— 这是第一道筛选 - 过滤「子查询该查哪条数据」，必须写在子查询内部的
WHERE—— 否则子查询可能返回空或错值 - 如果把主表过滤条件误塞进子查询，可能导致子查询无结果，从而把目标字段设为
NULL（且不报错）
容易忽略的一点：子查询没结果时，SET 赋值为 NULL，而很多人以为会跳过那行更新——不会跳过，只是静默设空。
