标量子查询返回多行必然报错，因=等标量操作符语义要求单值；应按业务意图改用in（集合匹配）或exists（存在性检查），select/update中需显式关联外层字段确保单值。
标量子查询返回多行时必然报错，不是数据库太严格，而是它在拒绝执行一个语义上无法成立的操作：你要求它返回“一个值”，它却给了你“一堆值”——数据库没法猜你要哪一行。
WHERE 中用 = 匹配子查询报错，立刻换 IN 或 EXISTS
错误现象：Subquery returns more than 1 row（MySQL）、ORA-01427（Oracle）、more than one row returned by a subquery（PostgreSQL）或 SQL Server 的 Subquery returned more than 1 value。
这不是数据量突增导致的偶发问题，而是写法与语义根本冲突：
- 你写了
WHERE status = (SELECT status FROM audit_log WHERE event_id = 123)，但event_id = 123对应 3 条日志 → 子查询返回 3 行 →=拒绝执行 - 本意其实是“status 属于这些值中的任意一个”，不是“等于某一个固定值”
正确做法按业务意图选：
- 想查“属于某集合” → 改用
IN：WHERE status IN (SELECT status FROM audit_log WHERE event_id = 123) - 想查“只要存在匹配记录就行” → 改用
EXISTS：WHERE EXISTS (SELECT 1 FROM audit_log WHERE event_id = 123 AND status = t.status) - 别用
= ANY替代IN：可读性差，且对NULL处理更隐晦；IN遇到全NULL子查询明确返回FALSE，而= ANY返回UNKNOWN，可能意外过滤数据
SELECT 列表里的子查询爆多行，补关联条件比加 LIMIT 1 可靠
错误现象：像 (SELECT meta_value FROM user_meta WHERE meta_title = 'user_image') 这种写法，没限定 user_id，一查就是全表扫描 —— 多个用户设了头像，就必然多行，直接报错。
DISTINCT 和 LIMIT 1 都不是解药：
-
DISTINCT只去重，不减行数；不同用户头像 URL 不同，DISTINCT后仍是多行 -
LIMIT 1无序时结果不可复现；SQL Server 强制要求配ORDER BY，否则语法报错；MySQL/PostgreSQL 允许但结果随机，上线前必须确认业务是否接受不确定性
正确做法是把外层主表字段带进去，写成相关子查询：
(SELECT um.meta_value FROM user_meta um WHERE um.user_id = team_request.user_id AND um.meta_title = 'user_image')- 这样每行只查自己对应的记录，结果天然唯一；若无匹配，自动返回
NULL，语义清晰 - 能利用
(user_id, meta_title)联合索引，性能也更好
UPDATE / SET 右侧子查询多行，必须显式关联或加聚合
错误现象：UPDATE orders SET status_name = (SELECT name FROM statuses WHERE code = 'shipped') 报错，因为子查询扫全表，返回所有 code = 'shipped' 的记录（哪怕只有一条，也不保证唯一）。
关键点在于：数据库要求 SET column = (subquery) 必须返回单值，但没关联外层字段的子查询本质上是“静态查询”，和当前被更新的行无关。
- 错误写法：
SET status_name = (SELECT name FROM statuses WHERE active = 1)→ 扫全表，必崩 - 正确写法：
SET status_name = (SELECT s.name FROM statuses s WHERE s.code = orders.status_code)→ 关联外层字段，自然唯一 - 若真存在一对多（如一个
status_code对应多个name），按业务选：ORDER BY updated_at DESC LIMIT 1（最新）、MAX(name)（字典最大）、或STRING_AGG(name, ', ')（拼接）
CROSS APPLY 是处理一对多展开的唯一合规路径
当你需要在每行主记录后“拉出它的前三条明细”，比如“每个订单的前 3 条商品”，SELECT (SELECT ... LIMIT 3) 写法在 SQL Server 直接被拒，MySQL/PostgreSQL 也会报错。
嵌套子查询在这里彻底失效，因为标量上下文无法容纳多行结果。
- 唯一合规路径是
CROSS APPLY：SELECT o.OrderID, d.ProductID FROM Orders o CROSS APPLY (SELECT TOP 3 ProductID FROM OrderDetails d WHERE d.OrderID = o.OrderID ORDER BY LineNumber) AS d - 必须带别名（
AS d），漏掉会报Incorrect syntax near '(' - 右侧若调用表值函数（如
STRING_SPLIT），函数本身已返回表，但仍需别名 -
CROSS APPLY本质是“对主表每一行，执行一次右侧表表达式”，天然支持一对多展开
最容易被忽略的是：错误常不在子查询本身，而在你没意识到它被放在了标量上下文中。比如在存储过程里写 SET @x = (SELECT id FROM t WHERE ...)，哪怕平时只返回一行，一旦某天数据异常就崩。别等报错才加防护，从写第一行子查询开始，就该明确它是否必须单值、由谁保证、不满足时怎么兜底。
