标量子查询必须返回且仅返回一个值，否则直接报错；它只能用于标量上下文（如比较运算符右侧、select列表、set赋值等），返回多行会触发数据库特定错误（如mysql的“subquery returns more than 1 row”），空结果则通常转为null。
标量子查询必须返回且仅返回一个值，否则直接报错——这不是数据库“不够智能”，而是 SQL 语义层面对表达式求值的基本要求。
标量子查询出现在哪里，就决定了它必须是单值
只要子查询被用在需要「标量上下文」的位置，数据库就必须能把它当做一个确定的值来参与运算。这些位置包括：
-
=、、>、IS NULL等比较运算符右侧 -
SELECT列表中单独一列（如(SELECT AVG(price) FROM products)） -
WHERE或HAVING中作为条件表达式的一部分 -
UPDATE ... SET col = (SELECT ...)的赋值右侧
一旦你写 WHERE id = (SELECT id FROM users WHERE status = 'active')，而实际有 3 个活跃用户，数据库无法决定该拿哪个 id 去比——它不是在“挑一个”，而是根本拒绝执行，抛出错误：子查询返回的值不止一个。
常见错误现象：报错信息直指上下文类型
不同数据库报错措辞略有差异，但核心一致：
- SQL Server：
消息 512，级别 16，状态 1：子查询返回的值不止一个 - MySQL：
Subquery returns more than 1 row - PostgreSQL：
more than one row returned by a subquery used as an expression
注意关键词：used as an expression 或 as an expression——这说明问题不在子查询本身，而在它被“当作表达式使用”的位置。换言之，只要把同一个子查询挪到 IN 或 EXISTS 后面，它就合法了，因为那属于「集合上下文」。
为什么不能自动取 TOP 1 或 LIMIT 1？
表面上看，加个 ORDER BY ... LIMIT 1 就能“强行变单值”，但这是危险的妥协：
- 结果不可靠：没
ORDER BY时，LIMIT 1返回哪一行是未定义的 - 语义丢失：你想查“最高单价商品”，写成
(SELECT price FROM products ORDER BY price DESC LIMIT 1)是对的；但若只是为绕过报错而硬加LIMIT 1，逻辑就变成“随便拿一个”，和原意相悖 - 掩盖设计缺陷：报错其实是提醒你——这个条件本就不该匹配多行，比如
WHERE user_id = (SELECT user_id FROM sessions WHERE token = ?)报错，说明 token 不唯一，该修复的是索引或业务逻辑，不是加LIMIT 1
真正该做的，是检查子查询的 WHERE 条件是否足够精确，或改用更合适的结构（如 IN、EXISTS、关联子查询）。
空结果集（零行）是个特例，但不等于“安全”
标量子查询返回零行时，多数数据库（如 MySQL、SQL Server）会将其视为 NULL，而非报错。例如：
SELECT name FROM employees WHERE dept_id = (SELECT id FROM departments WHERE name = 'Nonexistent');
这条不会报错，但查不到任何记录——因为子查询返回 NULL，而 dept_id = NULL 永远为 UNKNOWN（三值逻辑），整行被过滤掉。
容易被忽略的是：如果你后续在 SELECT 列表里用它，比如 (SELECT COUNT(*) FROM logs WHERE user_id = ?)，而该用户无日志，结果就是 0（不是 NULL）；但若写的是 (SELECT created_at FROM logs WHERE user_id = ? ORDER BY id DESC LIMIT 1)，没数据时就是 NULL。行为取决于聚合函数是否存在、是否带 ORDER BY 等细节，不能一概而论。
