标量子查询必须返回单行单列，否则报错；可出现在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 时），仅适用于“任取一个即可”的业务场景。
