标量子查询在UPDATE中必须返回0或1行，否则报错；MySQL报“Subquery returns more than 1 row”，PostgreSQL报“more than one row returned”，Oracle报ORA-01427；本质是语义要求单值赋值，多行即违反SQL标准。
因为子查询在 UPDATE 语句中必须返回单值，否则直接报错——MySQL 报 Subquery returns more than 1 row，PostgreSQL 报 more than one row returned by a subquery used as an expression，Oracle 报 ORA-01427。这不是警告，是硬性语法限制。
UPDATE 中的子查询本质是标量子查询
当你写 SET field = (SELECT ...)，数据库把括号里的整个 SELECT 当作一个“值”来用，就像写 SET field = 'abc' 一样。它只接受 0 行（结果为 NULL）或 1 行；2 行及以上就违反语义，立刻中断执行。
- 即使逻辑上你“知道”只该有一条匹配，数据库不会帮你推断，也不会自动取第一条
- 没加
WHERE关联主表字段（比如漏掉WHERE u.id = t.user_id），子查询就会扫全表，极易多行 - 关联字段未建索引时，即使条件正确，也可能因执行计划偏差导致重复扫描，间接放大风险
常见误写：关联条件写错或缺失表别名
典型错误是让子查询里的字段名“悬空”，比如在 UPDATE t SET x = (SELECT y FROM u WHERE id = id) 中，两个 id 都没指定来源表。数据库会当成 u.id = u.id，恒真，于是返回整张 u 表所有匹配 y 的行。
- 正确做法：给主表和子查询表都加别名，并显式写出关联，如
UPDATE t1 a SET a.name = (SELECT b.name FROM t2 b WHERE b.id = a.t2_id) - Oracle 尤其敏感，不加别名或别名冲突（如主表叫
users，子查询又写FROM users）会直接报table name "users" specified more than once - MySQL 8.0+ 对未限定列名更严格，部分版本会直接拒绝解析
加 LIMIT 1 是临时解法，不是修复
LIMIT 1（MySQL）或 AND ROWNUM = 1（Oracle）能压住报错，但掩盖了真正问题：数据逻辑是否允许多对一？结果是否可预期？
- 没
ORDER BY时，LIMIT 1返回哪一行完全由存储引擎决定，可能每次都不一样 - 如果业务要求“取最新一条”，必须明确写
ORDER BY created_at DESC LIMIT 1，否则更新结果不可重现 - 线上环境慎用——它绕过了约束检查，容易把脏数据写进主表，且后续排查困难
最稳妥的方式永远是先用 SELECT 模拟验证子查询：把整个 (SELECT ...) 单独拿出来跑一遍，加 GROUP BY 或 HAVING COUNT(*) > 1 检查是否有重复匹配。只要这一步不稳，UPDATE 就不可能安全。
