子查询用于UPDATE时结果准确取决于关联唯一性、NULL行为和执行顺序；否则易致重复更新、漏更新或字段变NULL，需通过去重、索引、COALESCE/EXISTS等手段严格控制。
子查询用于UPDATE时，结果是否准确不取决于“写得对不对”，而取决于你有没有控制住三件事：关联唯一性、NULL行为、执行顺序。
为什么UPDATE + 子查询容易更新错行
常见错误现象是某几行被反复更新、部分行没更新、或字段被设成NULL——根本不是语法报错，而是逻辑失控。
- MySQL 报
You can't specify target table 't1' for update in FROM clause说明你试图在子查询里直接读正在改的表，必须用派生表或关联子查询绕过 - PostgreSQL 不报错但更新了意外的行，大概率是子查询对同一个主表ID返回了多行（比如没加
DISTINCT ON或聚合） - SQL Server 静默执行多次更新，最后只保留最后一次匹配的结果，业务上等于“随机选一条”
确保一对一匹配的实操要点
无论用 JOIN 还是关联子查询，都必须让每条主表记录只对应一个子查询结果。
- 用
JOIN方式时，子查询里必须GROUP BY主键字段，且SELECT的字段只包含分组键和聚合值（如COUNT(*),MAX(updated_at)） - 用关联子查询（
SET col = (SELECT ... WHERE t2.id = t1.id)）时，WHERE 条件必须能命中至多一行；如果可能多行，加LIMIT 1（MySQL）或用ORDER BY ... FETCH FIRST 1 ROW ONLY（PostgreSQL） - 所有 JOIN 或子查询条件中，避免使用非索引字段（如
WHERE name = ...），否则会触发全表扫描+重复匹配
NULL 值和空匹配必须显式处理
子查询没查到数据时，默认把目标字段设为 NULL，这往往不是你想要的。
- 想跳过无匹配的行？用
WHERE EXISTS (SELECT 1 FROM ... WHERE ...)包一层 - 想保留原值？用
COALESCE((SELECT ...), t1.col)，但注意 MySQL 不允许在子查询里引用外层别名（t1.col要写成未加别名的列名） - 聚合子查询（如
SUM()）天然返回NULL当无匹配，需配合IFNULL()或COALESCE()显式转义
跨数据库写法差异最容易被忽略
同一段逻辑，在 MySQL、PostgreSQL、SQL Server 上写法不同，但意图必须一致：隔离读与写、强制唯一性、控制 NULL。
- MySQL 5.7 必须用关联子查询或
JOIN (SELECT ...) AS tmp，不能用FROM子句 - PostgreSQL 允许
UPDATE ... FROM (SELECT ...) s WHERE t.id = s.id，但子查询里绝不能出现主表名（连public.orders都不行） - SQL Server 的
UPDATE ... FROM看似简单，实际默认不校验匹配数，务必在子查询里用ROW_NUMBER() OVER (PARTITION BY id ORDER BY updated_at DESC)并WHERE rn = 1
真正难的不是写出能跑的语句，而是确认它在百万行数据、并发写入、索引缺失、历史脏数据等真实场景下，每次执行都返回相同结果。建议先用 SELECT 模拟子查询输出，再核对 JOIN 或 WHERE 条件是否真的能一一对应。
