子查询返回多行时用=会报错，因语义冲突；应改用ANY（存在即真）或ALL（全部满足），注意NULL影响及关联子查询场景下EXISTS更优。
子查询返回多行时直接用 = 报错 ORA-01427 或 Subquery returns more than 1 row
MySQL、Oracle、PostgreSQL 都会在 WHERE 中对单值比较（如 =、、<code>>）遇到多行子查询时立刻报错。这不是语法写错了，是语义冲突：你告诉数据库“找一个值等于这个子查询结果”，但它却返回了 5 行——数据库没法猜你想比哪一行。
常见错误场景包括：SELECT * FROM orders WHERE customer_id = (SELECT id FROM customers WHERE city = 'Beijing')，而北京有多个客户；或者误把 IN 的逻辑写成 =。
- 别硬加
LIMIT 1或ROWNUM = 1来“压”成一行——结果不可控，且掩盖了数据逻辑问题 - 如果本意确实是“任一匹配即可”，改用
ANY；如果要“全部满足”，才用ALL -
ANY等价于IN（仅用于=场景），但支持>、等比较符，<code>IN不支持
ANY 和 ALL 的实际行为差异
ANY 是“存在一个满足即为真”，ALL 是“全部满足才为真”。它们不是集合操作，而是逐行比较后做逻辑聚合，底层类似 OR / AND 展开。
例如：salary > ANY (SELECT salary FROM managers) 表示“比任意一个经理工资高就行”（即比最低经理工资还高）；而 salary > ALL (SELECT salary FROM managers) 表示“比所有经理工资都高”（即比最高经理工资还高）。
-
> ANY≈> MIN(...)，≈ <code> -
> ALL≈> MAX(...)，≈ <code> -
= ANY和IN功能一致，但IN更常用、可读性更好；ANY不等于NOT IN（NULL 处理不同，后面会提）
NULL 值让 ALL 和 ANY 行为反直觉
子查询若含 NULL，ALL 很容易“意外为真”，ANY 则可能“意外为假”。因为 SQL 的三值逻辑中，任何与 NULL 的比较结果都是 UNKNOWN，而 ALL 要求所有比较为 TRUE 才返回真——只要有一个 UNKNOWN，整个表达式就变成 UNKNOWN（在 WHERE 中等效于假）；但 ANY 只要有一个 TRUE 就成立，UNKNOWN 不影响它。
-
WHERE x > ALL (SELECT y FROM t)：若t中有NULL，该条件永远不成立（返回空结果），哪怕其他值都小于x -
WHERE x = ANY (SELECT y FROM t)：若t全是NULL，结果为空；但只要有一个非 NULL 匹配，就成立 - 安全做法：显式过滤 NULL，比如
(SELECT y FROM t WHERE y IS NOT NULL)
替代方案选型：什么时候该用 EXISTS 而不是 ANY
ANY 关注“值是否在集合中”，EXISTS 关注“是否存在满足条件的记录”。二者表面相似，但语义和性能差异明显。
例如查“有订单的客户”：SELECT * FROM customers c WHERE c.id = ANY (SELECT customer_id FROM orders) 会先执行子查询、生成临时结果集再比对；而 SELECT * FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id) 是对外部行逐条驱动，可能早停、更利于索引下推。
- 子查询无关联（不依赖外部表）→ 优先考虑
IN或物化临时表，ANY没优势 - 子查询有关联（用到外部列）→ 必须用
EXISTS或IN（部分数据库优化器能转，但不保证） -
ANY/ALL主要价值在支持>、等非等值比较，这是 <code>IN和EXISTS做不到的
真正容易被忽略的是 NULL 和关联性——写完 ANY 顺手一跑没报错，不代表逻辑正确；尤其当子查询来自视图或复杂 CTE 时，NULL 和空结果集的影响会藏得很深。
