标量子查询必须返回且仅返回一行一列，否则报错；空结果返回NULL，多行或多列均直接报错；其本质是标量上下文要求确定值，而非数据库实现缺陷。
标量子查询必须返回且仅返回一行一列，否则数据库直接报错——这不是实现缺陷，而是 SQL 表达式求值模型的刚性要求。
标量子查询出现在「标量上下文」中，数据库没有“选一个”的自由
当你写 WHERE user_id = (SELECT id FROM users WHERE status = 'active')，数据库不是在“从多行里挑一个匹配”，而是在执行一个表达式：user_id = ?。这个 ? 必须是一个确定的值，就像 5 或 NULL 一样。如果子查询返回 3 行，数据库连该把哪一行塞进等号右边都不知道，语义上就断了。
常见错误信息直指这点：
- MySQL：
Subquery returns more than 1 row - PostgreSQL：
more than one row returned by a subquery used as an expression - SQL Server：
Subquery returned more than 1 value
注意关键词：used as an expression——问题不在子查询本身，而在它被用的位置。
多列、多行、空结果，三者行为完全不同
标量子查询对结果形态极其敏感：
- 返回多行 → 立即报错（如上）
- 返回多列（如
SELECT id, name FROM users LIMIT 1）→ 同样报错，因为外层无法把两个字段压成一个标量值 - 返回空结果 → 不报错，结果为
NULL，参与比较时可能产生意外逻辑（比如WHERE x = (SELECT y...)在子查询无结果时整行被过滤掉）
最容易被忽略的是：你以为子查询该空，其实它漏写了关联条件，扫了全表，一执行就炸。调试时最有效的方法是把子查询单独拿出来跑：SELECT COUNT(*) FROM ...，比猜快十倍。
为什么不能自动加 LIMIT 1 或取 MAX()？
表面上加 LIMIT 1 能绕过报错，但这是危险的妥协：
- 没
ORDER BY时，LIMIT 1返回哪一行是未定义的，结果不可靠 -
MAX()或AVG()是兜底手段，但会掩盖真实问题：比如WHERE token = (SELECT user_id FROM sessions WHERE token = ?)报错，说明token字段没建唯一索引，该修的是数据约束，不是硬套聚合函数 - 语义错位：你想查“最新订单时间”，
(SELECT MAX(created_at) FROM orders)正确；但若只是为不报错而写(SELECT created_at FROM orders ORDER BY id DESC LIMIT 1)，那逻辑就变成“随便拿一条”，和原意相悖
什么位置算「标量上下文」？哪些地方可以放宽？
以下位置强制要求单值：
-
=、<>、>、IS NULL等比较运算符右侧 -
SELECT列表中独立一列（如SELECT name, (SELECT AVG(price) FROM products) AS avg_price） UPDATE ... SET col = (SELECT ...)-
WHERE或HAVING中作为条件表达式的一部分
而这些位置允许多行或多列：
-
IN右侧：必须单列，但可多行（WHERE id IN (SELECT id FROM t WHERE ...)） -
EXISTS：只关心是否有行，列数完全被忽略（SELECT a, b FROM t在EXISTS里完全合法） -
FROM子句中的派生表：可多行多列（SELECT * FROM (SELECT id, name FROM users) AS u）
真正该做的，不是强行让子查询变单值，而是先问一句：这个位置本该只对应一个值吗？如果不是，就换结构——用 IN、EXISTS 或显式 JOIN。
