在编写SQL查询时，标量子查询常被用来从关联表中取一个字段值拼到主查询的结果里。但当子查询实际返回了超过一行数据，主流关系型数据库都会中断执行并提示子查询返回了多行。理解这种错误的产生机制，并掌握用DISTINCT或LIMIT来兜底处理的方式，是写稳查询语句的基本功。
一、标量子查询为什么会报多行错误
标量子查询（scalar subquery）是指出现在SELECT列表、WHERE条件或HAVING子句中、且期望只返回单个值（一行一列）的子查询。数据库在展开执行计划时，会假设这个位置上的结果可以和一个标量直接比较或赋值。如果子查询因为关联条件不充分，命中了多条从表记录，执行器就无法把多行压缩成一个值，于是抛出类似“ORA-01427: single-row subquery returns more than one row”或者MySQL的“Subquery returns more than 1 row”的错误。
举个典型例子，订单表orders和订单明细表order_items是一对多关系。下面的语句想取出每个订单对应的一个商品名，但一个订单可能有多条明细，子查询自然返回多行：
SELECT o.id, o.user_id, (SELECT oi.product_name FROM order_items oi WHERE oi.order_id = o.id) AS product_name FROM orders o;
上面这段SQL在orders表中任意存在多个明细的订单上都会失败。根本问题在于，子查询没有对“取哪一条明细”做出限定，数据库不会自行挑选，只能报错。明确这一点后，我们才能判断该用去重还是限行来补救。
二、用DISTINCT处理返回多行
DISTINCT的核心作用是消去结果集中的重复行。当子查询返回的多行其实是完全相同的值时，加DISTINCT可以让结果集收敛成一行，从而满足标量的要求。它适用于“多行数据在业务上等价、只是由于表连接或数据冗余导致重复”的情况。
沿用前面的订单例子，假设同一个订单的多条明细确实可能写入了相同的商品名（比如拆单但商品不变），就可以这样改写：
SELECT o.id, o.user_id, (SELECT DISTINCT oi.product_name FROM order_items oi WHERE oi.order_id = o.id) AS product_name FROM orders o;
这里DISTINCT对product_name去重，如果同一个订单的所有明细商品名都一样，子查询就只剩一行，错误消失。但要注意，如果同一个订单的不同明细对应不同商品名，DISTINCT之后仍然有多行，报错依旧。因此DISTINCT并不是万能膏药，它只在值重复时有效。从执行成本看，DISTINCT会触发排序或哈希去重，数据量大时有一定开销，但一般小于误返回多行导致的失败重跑成本。
三、用LIMIT处理返回多行
LIMIT 1的思路更直接：不管子查询能查出多少行，只取第一行返回。这样从语法上彻底保证标量子查询最多输出一行。它适合“业务上只需要任意一个关联值、或者数据有序可控”的场景，比如取最近一次登录时间、取某个用户的最新评论内容。
把订单示例改成取该订单下任意一条明细的商品名，可写为：
SELECT o.id, o.user_id, (SELECT oi.product_name FROM order_items oi WHERE oi.order_id = o.id LIMIT 1) AS product_name FROM orders o;
加上LIMIT 1后，即使一个订单有上百条明细，子查询也只回传一条，不会再触发多行异常。但风险在于，数据库返回的是“碰巧排在前面的”那一条，若没有配合ORDER BY，哪条被选中是不确定的。在MySQL等库中，LIMIT不带ORDER BY时顺序依赖存储或执行计划。更稳妥的写法是加上排序，例如按明细ID倒序取最新一条：
SELECT o.id, o.user_id, (SELECT oi.product_name FROM order_items oi WHERE oi.order_id = o.id ORDER BY oi.id DESC LIMIT 1) AS product_name FROM orders o;
这种写法兼具稳定性和业务含义，是实际项目里更推荐的兜底方式。不过LIMIT本质是“截断”，如果业务要求汇总多个值（例如把所有商品名拼起来），那就不能用LIMIT，而应该用GROUP_CONCAT或STRING_AGG等聚合函数，从根上改变子查询形态。
四、两种方案对比与选用建议
为了更直观看到差别，可以从语义、适用场景和风险三个维度比较：
| 处理方式 | 作用原理 | 适用场景 | 主要风险 |
|---|---|---|---|
| DISTINCT | 对子查询结果去重，重复值合并为一行 | 多行值完全相同，业务上视为同一值 | 值不同时依旧多行，无法解决本质差异 |
| LIMIT 1 | 强制只取第一行，忽略其余记录 | 只需任意一条，或配合ORDER BY取特定一条 | 无ORDER BY时选取不确定，可能丢业务数据 |
从工程实践看，优先应该检查关联条件是否漏写、是否该用聚合（如MAX、MIN）来归约。DISTINCT和LIMIT更多是应急或明确语义下的简化写法。若团队代码规范允许，建议在LIMIT方案里强制要求ORDER BY，避免不同环境执行计划变化引发数据漂移。
另外，在PostgreSQL里标量子查询返回零行会得到NULL而不是报错，返回多行才报错；MySQL和Oracle则在多行时直接失败。跨库迁移SQL时要留意这种细节，不能假定一种数据库的行为在另一种里也成立。理解底层机制后，面对“标量子查询返回多行”的报错，就能快速判断是补DISTINCT去重，还是加LIMIT限行，抑或重构为连接查询。
五、改写为JOIN的更优思路
除了在子查询内部动手，很多时候把标量子查询改成LEFT JOIN再配合聚合，能从结构上避免多行问题。例如上面的订单取商品名，如果确实只需要一个，可以用如下写法：
SELECT o.id, o.user_id, MAX(oi.product_name) AS product_name FROM orders o LEFT JOIN order_items oi ON oi.order_id = o.id GROUP BY o.id, o.user_id;
通过GROUP BY订单维度，再用MAX取其中一个商品名，既明确了“多值归约”的意图，也省去了标量子查询的执行限制。在复杂报表里，这种写法通常比嵌套子查询更易优化器展开。当然，若主表本身要保留多行、且子查询只是补充列，标量子查询加LIMIT仍是最简洁的表达。技术选型时权衡可读性与执行效率即可。