子查询在WHERE中报“subquery returns more than one row”错误，因=、>等标量操作符要求子查询返回单值；多值匹配应改用IN，存在性判断优先用EXISTS；窗口函数禁止出现在WHERE中；相关子查询易导致索引失效，建议改写为JOIN或实测执行计划。
WHERE里写子查询为什么报错“subquery returns more than one row”
因为大多数数据库（MySQL、PostgreSQL、SQL Server）在 WHERE col = (subquery) 这种形式中，要求子查询必须返回**单值**。一旦子查询返回多行，就直接报这个错。
常见场景是：你想查“订单金额大于该用户平均订单金额的订单”，但写成 WHERE amount > (SELECT AVG(amount) FROM orders o2 WHERE o2.user_id = o1.user_id) —— 这个子查询其实没问题；但如果误写成 WHERE user_id = (SELECT id FROM users WHERE status = 'active')，而 status = 'active' 对应多个用户，就炸了。
- 用
=或>等标量比较符时，子查询必须加LIMIT 1（MySQL）或FETCH FIRST 1 ROW ONLY（PostgreSQL/SQL Standard），但更推荐先确认业务逻辑是否真要单值 - 想匹配多值？改用
IN：WHERE user_id IN (SELECT id FROM users WHERE status = 'active') - 想做存在性判断？用
EXISTS更安全、通常也更快：WHERE EXISTS (SELECT 1 FROM orders o2 WHERE o2.user_id = users.id AND o2.amount > 1000)
EXISTS 和 IN 在 WHERE 中性能差很多吗
不一定，但行为和优化路径完全不同： IN 先执行子查询、缓存结果集，再对外表每行做哈希查找；EXISTS 是对外表每行触发一次子查询（correlated subquery），但可利用索引提前终止。
典型坑是：当子查询结果集很大且无索引时，IN 可能吃光内存或生成巨大临时表；而 EXISTS 即使子查询慢，只要外层能走索引+内层有合适索引（比如 WHERE o2.user_id = users.id 中 o2.user_id 有索引），就能快速响应。
- 子查询结果固定且小（如几十个配置ID）→ 用
IN更直观 - 子查询依赖外层字段（correlated）、且关联字段有索引 → 优先选
EXISTS - MySQL 5.7+ 对
IN (subquery)有 semi-join 优化，但 PostgreSQL 和 SQL Server 仍倾向EXISTS处理相关子查询 - 别在
IN里写SELECT *，只选必要列（哪怕只写1）——部分引擎会少传数据
WHERE 中用窗口函数会怎样
直接报错。所有主流 SQL 引擎都禁止在 WHERE 中使用窗口函数（如 ROW_NUMBER()、RANK()），因为 WHERE 执行阶段早于窗口计算阶段——数据还没分组、排序、编号，根本拿不到结果。
想实现“取每个用户最新一条订单”，不能写 WHERE rn = 1（rn 来自 ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)），那是语法错误。
- 正确做法：用派生表或 CTE 先算出窗口值，再在外层过滤：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (...) AS rn FROM orders) t WHERE t.rn = 1 - 注意 CTE 不是万能加速器——PostgreSQL 会物化，MySQL 8.0+ 默认不物化，但优化器可能重写；关键还是看执行计划里有没有
WindowAgg提前于Filter - 如果只是取 Top-N，
LIMIT+ORDER BY更轻量，但无法按组取 Top-N；这时窗口函数仍是刚需，只是不能塞进WHERE
WHERE 子句里嵌套子查询影响索引使用吗
会影响，而且很隐蔽。外表的索引是否生效，取决于优化器能否把子查询“解耦”出来。比如 WHERE status = 'paid' AND amount > (SELECT AVG(amount) FROM orders o2 WHERE o2.status = 'paid')，这个子查询是独立的，优化器大概率会先算出平均值，再用 status 和 amount 走联合索引。
但如果是相关子查询：WHERE amount > (SELECT AVG(amount) FROM orders o2 WHERE o2.user_id = orders.user_id)，外表每行都要跑一次子查询，即使 user_id 有索引，优化器也可能放弃外表的 amount 索引，转为全表扫描+嵌套循环。
- 检查执行计划：找
DEPENDENT SUBQUERY（MySQL）或SubPlan（PostgreSQL）节点，旁边有没有索引扫描（Index Scan） - 把相关子查询拆成 JOIN，往往能唤醒索引：
SELECT o1.* FROM orders o1 JOIN (SELECT user_id, AVG(amount) avg_amt FROM orders GROUP BY user_id) o2 ON o1.user_id = o2.user_id WHERE o1.amount > o2.avg_amt - 某些场景下，
JOIN会放大中间结果集（比如一对多），这时反不如EXISTS稳定——得实测，别只看理论
最麻烦的不是语法写不对，而是执行计划看起来走了索引，但实际每次子查询都触发磁盘随机读。上线前务必用真实数据量 explain，别信本地小表测试结果。
