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，有时优化器更友好 - 高频动态条件（如后台筛选）考虑预计算中间表，或用
MATERIALIZEDCTE（PostgreSQL 12+）
真正难处理的从来不是语法怎么写，而是子查询是否被物化、关联字段有没有覆盖索引、以及优化器到底信不信你的EXISTS能提前终止。
