WHERE中子查询报“Subquery returns more than 1 row”错误，因=、>等标量运算符要求子查询返回单值；多值匹配应改用IN，存在性判断优先用EXISTS，相关子查询需加表别名避免未知列错误。

WHERE子句里直接写(SELECT ...)为什么报错？

因为单行子查询返回多于一行时，=、>这类比较运算符会直接报错：Subquery returns more than 1 row。不是语法写错了，是语义不匹配——你用单值比较操作符，却塞进去一个结果集。

解决方向只有两个：要么确保子查询只返回一行（加LIMIT 1或聚合），要么改用支持多值的谓词。

• 需要“等于某集合中任意一个值” → 用 IN
• 需要“大于所有值”或“小于任意一个值” → 用 ALL / ANY
• 需要“存在/不存在匹配记录” → 用 EXISTS（推荐，性能通常更好）

IN vs EXISTS：什么时候选哪个？

IN适合简单枚举类场景，比如查“订单状态属于待发货、已发货的订单”：status IN (SELECT code FROM order_status WHERE category = 'shipping')。但要注意：IN对NULL敏感——如果子查询结果含NULL，整条IN判断会返回UNKNOWN，导致该行被过滤掉（即使其他值匹配）。

EXISTS更安全、也更贴近业务逻辑：“查有对应支付记录的订单”：WHERE EXISTS (SELECT 1 FROM payment p WHERE p.order_id = o.id)。它不关心子查询返回什么值，只看是否存在匹配行；且不受NULL影响。

• 子查询字段少、外层表大 → 优先EXISTS（可利用关联字段索引）
• 子查询结果集小且稳定（如配置表）→ IN可读性更高
• 子查询含GROUP BY或复杂计算 → 避免IN，改用JOIN或EXISTS

嵌套查询里引用外部表字段，为什么提示“Unknown column”？

这是作用域问题。MySQL 5.7+ 和 PostgreSQL 支持相关子查询（correlated subquery），但字段引用必须明确到表别名，尤其当外层和内层表有同名列时。

错误写法：WHERE id IN (SELECT order_id FROM payment WHERE status = 'success') —— 这里order_id没歧义，但一旦外层也有order_id，就可能报错。

正确写法：WHERE o.id IN (SELECT p.order_id FROM payment p WHERE p.order_id = o.id AND p.status = 'success')，其中o是外层订单表别名。

• 始终给外层表显式加别名（如orders o）
• 子查询中所有跨层引用都带别名前缀，避免隐式解析失败
• PostgreSQL 要求相关列必须出现在子查询的WHERE或ON中，不能只在SELECT里

性能突然变慢，是不是嵌套查询惹的祸？

是。相关子查询在 MySQL 中可能被重复执行（每行外层数据触发一次子查询），尤其在外层结果集大时，O(N×M)复杂度很致命。

典型症状：加了EXISTS后执行时间从 50ms 涨到 8s，EXPLAIN显示type=ALL或rows远超预期。

• 检查子查询是否能走索引：关联字段（如p.order_id）必须有索引
• 把EXISTS等价改写为LEFT JOIN ... WHERE xxx IS NOT NULL，有时优化器更友好
• 高频动态条件（如后台筛选）考虑预计算中间表，或用MATERIALIZED CTE（PostgreSQL 12+）

真正难处理的从来不是语法怎么写，而是子查询是否被物化、关联字段有没有覆盖索引、以及优化器到底信不信你的EXISTS能提前终止。