标量子查询必须返回单行单列，否则报错；空结果返回NULL，多行触发错误，安全写法需通过主键/唯一键确保1:1关联，性能敏感时优先LEFT JOIN。
标量子查询必须返回单个值，否则报错
在 SELECT 列表里写子查询，本质是标量子查询（scalar subquery）：它必须且只能返回一行一列。一旦子查询结果为空（NULL），SQL 会正常返回 NULL；但若返回多行，绝大多数数据库（如 PostgreSQL、MySQL 8.0+、SQL Server、Oracle）会直接报错，例如 PostgreSQL 报 more than one row returned by a subquery used as an expression，MySQL 报 Subquery returns more than 1 row。
常见踩坑点：
- 忘了加
WHERE条件或关联条件，导致子查询扫描全表 - 用
IN或= ANY(...)替代了单值比较，实际仍可能多行 - 误把聚合查询当标量用——没加
GROUP BY或漏写MAX()/MIN()等聚合函数
用 WHERE + 主键/唯一键关联，确保一对一关系
标量子查询要安全，核心是让它和外部行形成确定的 1:1 关联。最稳妥的方式是通过主键或唯一约束字段做等值连接。
比如查每个订单的客户姓名（orders 表有 customer_id，customers 表主键为 id）：
SELECT order_id, (SELECT name FROM customers WHERE id = orders.customer_id) AS customer_name, amount FROM orders;
这个写法成立的前提是：customers.id 是主键（或至少是唯一非空），否则仍可能返回多行。如果 customer_id 允许为 NULL，子查询自动返回 NULL，无需额外处理。
注意：
- 别用
JOIN的思路去写子查询——例如(SELECT name FROM customers c JOIN orders o ON c.id = o.customer_id)是错的，它脱离了外层orders的当前行上下文 - 子查询里不能引用外层未暴露的列（比如
orders.created_at在子查询中不可见，除非显式传入）
性能敏感时，优先考虑 LEFT JOIN 而非标量子查询
标量子查询在逻辑上清晰，但执行效率通常不如 LEFT JOIN。数据库往往对每个外层行单独执行一次子查询，无法有效利用索引下推或批量 join 优化。
对比下面两种写法：
-- 标量子查询（可能慢） SELECT id, (SELECT status_name FROM statuses WHERE id = t.status_id) AS status FROM tickets t;
-- 等价的 LEFT JOIN（通常更快） SELECT t.id, s.status_name AS status FROM tickets t LEFT JOIN statuses s ON s.id = t.status_id;
只有在以下情况才倾向用标量子查询：
- 只需要取一个字段，且关联表不参与其他筛选或排序
- 子查询含聚合或条件逻辑（如
(SELECT COUNT(*) FROM logs WHERE ticket_id = t.id AND type = 'error')） - 跨多个不同维度动态拼列（比如同时查客户名、最新订单时间、未读消息数），用多个标量子查询比多表
LEFT JOIN更易读、更少笛卡尔风险
PostgreSQL 和 MySQL 对 NULL 处理一致，但 Oracle 需注意
现代主流数据库对标量子查询返回空集的行为统一：结果为 NULL。但 Oracle 有个历史细节：如果子查询在 SELECT 列表中且返回空，它不会报错，但某些旧版本驱动或工具可能误判为异常。
更关键的是 Oracle 的相关限制：
- 子查询不能包含
ROWNUM（会报ORA-00936: missing expression） - 不能在子查询里用
ORDER BY（除非配合FETCH FIRST，如ORDER BY created_at DESC FETCH FIRST 1 ROW ONLY） - 若需取“最新一条”，必须显式加
FETCH FIRST 1 ROW ONLY或用MAX()等聚合，否则语法不通过
所以跨数据库写标量子查询时，宁可多写一层聚合或限制，也不要依赖隐式行为。
真正难的不是语法，而是判断“这个值是否真能靠一行子查询稳稳取到”——它背后的数据一致性、索引覆盖、并发更新场景，往往比写法本身更值得花时间确认。
