标量子查询必须返回一行一列，否则报错；空值返回null，多行或多列直接中断执行；安全写法是用主键/唯一键显式关联，性能差时优先用left join替代。
标量子查询必须返回一行一列，否则直接报错
在 SELECT 列表里写子查询，数据库会强制要求它只返回一个值——也就是「一行一列」。这不是建议，是硬性约束。一旦子查询结果为空，返回 NULL；但只要返回两行或两列，绝大多数数据库（MySQL 8.0+、PostgreSQL、SQL Server、Oracle）立刻中断执行，抛出类似 Subquery returns more than 1 row 或 more than one row returned by a subquery used as an expression 的错误。
常见触发点包括：
- 漏写
WHERE条件，导致子查询扫描整张表 - 误用聚合函数却没加
GROUP BY，比如(SELECT SUM(amount) FROM orders)在外层有GROUP BY user_id时仍可能多行（取决于优化器行为） - 用
=比较却写了IN风格的子查询，例如(SELECT name FROM customers WHERE city = 'Beijing')—— 北京可能有多个客户
安全写法：用主键/唯一键做显式关联
要让标量子查询稳定返回单值，最可靠的方式是让它和外层当前行形成确定的 1:1 关系。核心是靠主键或唯一约束字段做等值匹配。
比如查每个订单的客户名：
SELECT order_id,
(SELECT name FROM customers WHERE id = orders.customer_id) AS customer_name,
amount
FROM orders;
这个写法成立的前提是：customers.id 是主键（或至少是 UNIQUE NOT NULL）。如果 orders.customer_id 为 NULL，子查询自动返回 NULL，无需额外处理。
容易踩的坑：
- 在子查询里写
JOIN，例如(SELECT c.name FROM customers c JOIN orders o ON c.id = o.customer_id)—— 它脱离了外层orders的当前行上下文，必然多行 - 引用外层未暴露的字段，比如
orders.created_at在子查询中不可见，除非显式传入 - 把
WHERE条件写成模糊匹配（如LIKE），破坏唯一性保证
性能敏感时，LEFT JOIN 通常比标量子查询快得多
标量子查询逻辑清晰，但执行机制是「对外层每一行，单独执行一次子查询」。数据库很难下推索引、做批量优化，尤其在外层数据量大时，I/O 和 CPU 开销明显升高。
等价的 LEFT JOIN 写法：
SELECT t.id, s.status_name AS status FROM tickets t LEFT JOIN statuses s ON s.id = t.status_id;
优势在于：
- 一次哈希连接或索引查找即可完成全部关联
- 能利用
statuses.id上的索引加速匹配 - 空值处理自然（
s.status_name为NULL当无匹配）
只有当关联逻辑复杂到难以用 JOIN 表达（比如需要子查询内嵌聚合再过滤），才考虑保留标量子查询。
算占比或做除法时，NULL 和除零必须手动兜底
在 SELECT 列表里用子查询算比例，比如「部门人数占全公司比例」，很容易掉进两个坑：分子或分母为 NULL，或分母为 0。
错误示范：
SELECT dept, COUNT(*) * 100 / (SELECT COUNT(*) FROM employees) AS pct FROM employees GROUP BY dept;
正确写法要组合 NULLIF 和 COALESCE：
SELECT dept, COUNT(*) AS cnt,
COALESCE(COUNT(*) * 100.0 / NULLIF((SELECT COUNT(*) FROM employees), 0), 0) AS pct
FROM employees GROUP BY dept;
注意点：
-
NULLIF(expr1, expr2)在分母为 0 时返回NULL，避免除零错误 -
COALESCE(..., 0)把最终的NULL（来自除零或分子为NULL）转成 0 - 乘以
100.0而非100，防止整数除法截断（尤其在 PostgreSQL、SQL Server 中）
真正难的不是写对语法，而是想清楚：这个子查询是否真的需要出现在 SELECT 列表里？很多时候，用窗口函数（如 SUM() OVER()）替代，既安全又高效，还免去手动处理空值的麻烦。
