标量子查询必须返回单值，否则报错；常见问题包括未加LIMIT 1、漏写GROUP BY、相关条件缺失；性能差于JOIN，仅适用于小数据量场景。
标量子查询必须返回单值，否则直接报错
标量子查询用在 SELECT 列表、WHERE 条件或 ORDER BY 中时，数据库会强制要求它只返回一行一列。一旦子查询结果是 0 行或 >1 行，MySQL 报 Subquery returns more than 1 row，PostgreSQL 报 more than one row returned by a subquery used as an expression。
常见踩坑点：
- 没加
LIMIT 1且关联字段不唯一（比如用user_id查用户昵称，但昵称表里有历史重复记录） - 用了聚合但漏写
GROUP BY，导致逻辑上多行（如SELECT AVG(score) FROM exam WHERE user_id = t.user_id没问题，但加了subject又没分组就危险） - 误把相关子查询写成非相关（比如忘了写
WHERE child.parent_id = parent.id，结果查出全表平均值，看似不报错，但值错得离谱）
SELECT 列表里嵌标量子查询，性能比 JOIN 差很多
当你要从主表每行都“拉”一个附属值（比如订单表每行带客户等级），用标量子查询写起来顺手：(SELECT level FROM customer WHERE id = order.customer_id)。但它本质是「对主表每一行执行一次独立查询」，N 行就是 N 次查询。
实操建议：
- 数据量小（
- 超过 1w 行务必改用
LEFT JOIN—— 先查出所有需要的附属数据，再一次性关联，I/O 和执行计划更可控 - 如果子查询涉及聚合（如统计该客户的订单总数），仍建议先用
GROUP BY预聚合，再JOIN，别让它在SELECT里反复算
WHERE 中用标量子查询做条件过滤，注意 NULL 处理
比如写 WHERE (SELECT status FROM audit_log WHERE ref_id = order.id ORDER BY ts DESC LIMIT 1) = 'approved'，看着没问题，但只要子查询没匹配到任何记录，整个表达式结果就是 NULL，而 NULL = 'approved' 永远为 FALSE（不是 TRUE 也不是 FALSE，是未知），这行就被过滤掉了——可能不是你想要的“没审核记录也算通过”的逻辑。
关键处理方式：
- 用
IS NOT NULL显式判断是否存在（(SELECT ...) IS NOT NULL） - 用
COALESCE提供默认值（COALESCE((SELECT ...), 'pending')） - 更稳妥的做法：把子查询挪到
FROM或LATERAL（PostgreSQL）/APPLY（SQL Server）中，让 NULL 可控地参与连接
复杂报表里混用标量子查询和窗口函数容易出错
想在一个查询里既用标量子查询取某个参考值（比如全公司平均薪资），又用 ROW_NUMBER() 排序，要注意执行顺序：标量子查询在 SELECT 阶段执行，而窗口函数在 SELECT 之后、ORDER BY 之前计算。这意味着标量子查询看不到窗口函数生成的序号，但能读到原始行数据。
典型陷阱：
- 写
(SELECT COUNT(*) FROM emp WHERE dept = e.dept)是安全的；但写(SELECT COUNT(*) FROM (SELECT *, ROW_NUMBER() OVER(...) rn FROM emp) t WHERE t.dept = e.dept AND t.rn 就不行——标量子查询不能引用外层的窗口别名 <code>e，也不能嵌套访问未完成的窗口计算 - 如果真要结合，优先把窗口逻辑提前提取到 CTE，再让标量子查询基于 CTE 查询
- 多数情况下，这类需求用聚合 +
GROUP BY或JOIN更稳，标量子查询在这里属于“炫技易翻车”区域
标量子查询真正的优势场景很窄：动态取单值、逻辑无法提前聚合、且主表行数可控。一旦报表变大、条件变多、或者需要跨层级比较，它就不再是“灵活”，而是“难 debug”了。
