标量子查询必须返回单行单列，否则报错；可出现在SELECT、WHERE、HAVING、INSERT/UPDATE的值位置，不可用于FROM/GROUP BY/ORDER BY；空结果返回NULL；性能上可能关联执行多次，需索引或改写为JOIN优化。

标量子查询必须返回且仅返回一行一列，否则运行时会报错。

标量子查询的语法位置限制

只能出现在允许单值表达式的地方，比如：

• SELECT 列表中（如 SELECT name, (SELECT COUNT(*) FROM orders WHERE user_id = u.id) AS order_count FROM users u）
• WHERE 或 HAVING 子句中作为比较值（如 WHERE salary > (SELECT AVG(salary) FROM employees)）
• INSERT 的 VALUES 子句或 SET 子句中
• UPDATE 的 SET 后面（如 SET status = (SELECT default_status FROM config)）

不能直接用在 FROM 子句中（那是派生表/内联视图），也不能用在 GROUP BY 或 ORDER BY 中作为独立项（除非该子查询本身是确定性单值且被数据库允许，但语义上不推荐）。

空结果集与 NULL 的处理

标量子查询未查到任何行时，结果为 NULL，不是错误。例如：

SELECT (SELECT email FROM users WHERE id = 99999) AS email; → 返回 NULL

这意味着它可安全用于外键缺失、配置未设置等场景，但需注意后续逻辑是否能正确处理 NULL（比如在 WHERE 中使用 = NULL 永远为 false，应改用 IS NULL）。

性能与执行行为要点

多数数据库会对相关标量子查询进行“关联执行”，即对主查询每一行都重新计算一

次子查询（类似嵌套循环）。例如：

SELECT id, (SELECT COUNT(*) FROM logs l WHERE l.user_id = u.id) cnt FROM users u;

若 users 有 10 万行，logs 有千万行，该语句可能触发千万级关联扫描。优化方向包括：

• 确保子查询中的关联字段有索引（如 logs(user_id)）
• 考虑改写为 LEFT JOIN + 聚合（通常更高效）
• 若子查询不依赖主查询（即无相关列），数据库可能只执行一次并复用结果

常见错误与规避方式

典型报错：Subquery returns more than 1 row（MySQL）或 more than one row returned by a subquery used as an expression（PostgreSQL）。

原因多为缺少约束条件或聚合误用。例如：

• 漏写 WHERE 中的关联条件：(SELECT name FROM users) → 全表多行
• 误用非聚合查询替代聚合需求：(SELECT created_at FROM posts WHERE user_id = u.id) → 若用户有多篇文章，就失败
• 应改为 (SELECT MAX(created_at) FROM posts WHERE user_id = u.id) 或加 LIMIT 1（部分数据库支持，但语义需明确）

注意：LIMIT 1 可避免报错，但结果不可预测（无 ORDER BY 时），仅适用于“任取一个即可”的业务场景。