子查询在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，别信本地小表测试结果。