应根据业务意图选择in、exists、关联子查询或order by+limit等正确语法，而非简单加limit 1；子查询多行错误主因是缺失筛选条件或语义不匹配。
UPDATE 语句里子查询返回多行，直接报错（MySQL 是 1242 Subquery returns more than 1 row，Oracle 是 ORA-01427，SQL Server 是 “Subquery returned more than 1 value”），这不是语法写错了，是语义冲突：SET 后面必须填一个确定的值，不能塞一堆。
WHERE 条件没关联外层行？先加关联字段
最常见原因是子查询漏了对外层表的引用，变成非相关子查询，一查就是全表匹配。
比如写成：
UPDATE orders SET status = (SELECT name FROM statuses WHERE code = 'shipped')
这没问题——只要 statuses 里 code = 'shipped' 真只有一条；但若本意是“每个订单对应的状态名”，却忘了连到 orders.status_code，就会错写成：
UPDATE orders SET status = (SELECT name FROM statuses WHERE code = orders.status_code)
注意：上面这句其实正确；错误写法是漏掉 orders.status_code，比如：
UPDATE orders SET status = (SELECT name FROM statuses WHERE active = 1)
这就查出所有 active=1 的状态名，必然多行。修复要点：
- 检查子查询 WHERE 中是否包含外层表字段（如
orders.status_code） - 确认该字段在子查询中被当作等值条件使用，而非常量或未限定范围的列
- 用
EXPLAIN或执行计划看子查询是否标记为DEPENDENT SUBQUERY（MySQL）或Correlated Subquery（PostgreSQL）
子查询真有多行匹配？按业务意图选方案
关联上了，但数据本身一对多（比如一个 corp_key 对应多个 CORP_NAME），就得明确业务要什么：
- 只要任一值（且任意一个都可接受）→ 加
ORDER BY + LIMIT 1（MySQL/PG）或TOP 1（SQL Server），但必须带ORDER BY，否则结果不可控 - 要最新/最早那条 → 显式
ORDER BY created_at DESC LIMIT 1，别只靠LIMIT - 要聚合结果（如取最长名称、最大 ID）→ 改用
MAX(name)或MIN(id)，前提是业务允许丢细节 - 要拼成字符串（如逗号分隔）→ MySQL 用
GROUP_CONCAT()，PostgreSQL 用STRING_AGG()，Oracle 用LISTAGG()，但注意长度限制和 NULL 处理
UPDATE 里用 IN 或 EXISTS？不行，语法不支持
IN 和 EXISTS 解决的是 WHERE 条件里的多行判断，不是 SET 右侧的赋值。下面这些写法都非法：
UPDATE users SET name = (SELECT name FROM admins WHERE id = users.admin_id) WHERE id IN (SELECT user_id FROM logs)
上面的子查询在 SET 里仍需单行；WHERE 部分用 IN 没问题，但不解决左侧赋值问题。容易踩的坑：
- 误以为加个
WHERE 1=1或AND ROWNUM = 1就安全——Oracle 的ROWNUM是查完才编号，没ORDER BY就没意义 - 在 SQL Server 里对子查询用
TOP 1却不写ORDER BY→ 直接语法报错 - 用
DISTINCT试图去重 → 它不减少行数，只去相同值，一对多时照样爆
先 SELECT 再 UPDATE，永远是最稳的路径
别在 UPDATE 里硬扛复杂逻辑。先写个 SELECT 查出你要更新的映射关系，确认每行外键确实只对应一个目标值：
SELECT o.id, s.name FROM orders o JOIN statuses s ON o.status_code = s.code WHERE o.id IN (1001, 1002, 1003)
如果这一步就返回多行 per o.id，说明数据模型或业务规则本身就有歧义——这时候强行 UPDATE 只会埋雷。真正该做的，是：
- 查
GROUP BY+HAVING COUNT(*) > 1定位脏数据（如SELECT STOCKHOLDER_CORP_KEY, COUNT(*) FROM corp_info GROUP BY STOCKHOLDER_CORP_KEY HAVING COUNT(*) > 1） - 跟产品确认：一个
CORP_KEY真该对应多个CORP_NAME吗？要不要加生效时间、版本号等维度来收束 - 上线前在测试库跑
BEGIN; UPDATE ...; SELECT ROW_COUNT(); ROLLBACK;看影响行数是否符合预期
子查询多行报错本身不是技术难点，而是数据语义暴露出来的信号——它在问你：“你真的清楚这一行该填什么吗？”
