标量子查询报错“Subquery returns more than 1 row”需确保其严格返回一行一列：先用COUNT(*)验证子查询结果行数，>1时应补全关联条件或加WHERE过滤；慎用LIMIT 1（须配ORDER BY保证语义正确），优先改用聚合函数、JOIN或IN/EXISTS替代。
标量子查询能直接返回一个值，但前提是它必须严格返回一行一列——否则运行时会报错。
标量子查询报 Subquery returns more than 1 row 怎么办？
这是最常见的失败场景：你以为子查询只匹配一条记录，实际查出了多条。
- 先用
SELECT COUNT(*)检查子查询本身是否真的单行：SELECT COUNT(*) FROM orders WHERE customer_id = 123;
- 如果结果 > 1，必须加限制条件，比如
LIMIT 1（MySQL）或TOP 1（SQL Server），但要注意语义是否合理——取哪一条？要不要加ORDER BY？ - 更安全的做法是检查业务逻辑：是否漏了时间范围、状态过滤（如
WHERE status = 'completed'）？
在 WHERE 子句里用标量子查询要注意什么？
标量子查询可以出现在 WHERE 中作比较值，但不能替代 IN 或 EXISTS 的语义。
- ✅ 正确：
WHERE amount > (SELECT AVG(amount) FROM sales)—— 子查询返回单个平均值 - ❌ 错误：
WHERE customer_id IN (SELECT id FROM customers WHERE region = 'US')改成标量写法：WHERE customer_id = (SELECT id FROM customers WHERE region = 'US')—— 一旦 US 有多个客户就崩 - ⚠️ 注意 NULL：如果子查询没结果，返回
NULL，而WHERE col = NULL永远为 false（要用IS NULL显式判断）
SELECT 列表里的标量子查询为什么慢？
每行主查询记录都会独立执行一次子查询，没有缓存，容易形成 N+1 查询问题。
- 例如：
SELECT name, (SELECT COUNT(*) FROM orders o WHERE o.customer_id = c.id) AS order_count FROM customers c—— 对每个客户都扫一遍 orders 表 - 优化方向：改用
LEFT JOIN+GROUP BY，或提前物化聚合结果（如用 CTE 预算好每个客户的订单数） - 某些数据库（如 PostgreSQL）支持 LATERAL JOIN，可让子查询“感知”外层别名并更好下推条件
标量子查询看着简洁，但它的单行约束和执行时机是硬性边界，不是语法糖——写之前得确认数据唯一性，上线前得压测性能表现。
