子查询返回多行时使用=或!=会报错，因单行比较运算符要求子查询结果至多一行；应改用IN、NOT IN、ANY、ALL等多行比较运算符。
子查询返回多行却用了 =、!=、
这是最常见报错场景，比如 MySQL 报 Subquery returns more than 1 row，PostgreSQL 报 more than one row returned by a subquery used as an expression。根本原因是把本该返回单值的标量上下文（如 WHERE col = (SELECT ...)）误塞进了多行结果。
解决方法不是强行加 LIMIT 1（会掩盖逻辑错误），而是检查业务意图：
- 想判断是否存在匹配？改用
IN或EXISTS - 想取某个聚合结果？补上
MAX()、COUNT()等聚合函数 - 真需要逐行比对？把子查询提到
FROM子句做连接（JOIN）
用 IN 还是 EXISTS 处理“是否属于某集合”类需求
IN 和 EXISTS 都能处理多行子查询，但语义和性能差异明显：
-
IN适合子查询结果集小、且不含NULL的场景；一旦子查询返回NULL，整条IN判断会变UNKNOWN，可能漏数据 -
EXISTS只关心是否存在匹配行，不取实际值，通常更快（尤其外层表小、内层表大时），且不受NULL影响 - 示例：查有订单的用户 →
SELECT * FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)
子查询在 SELECT 列表中返回多行的写法限制
标准 SQL 不允许 SELECT (SELECT name FROM cities WHERE country_id = c.id) 这种写法返回多行——它必须是标量子查询。如果真要展开关联的多行数据（如一个用户的所有邮箱），得换思路：
- 用
STRING_AGG()（PostgreSQL）、GROUP_CONCAT()（MySQL）或LISTAGG()（Oracle）聚合成字符串 - 用
LATERAL（PostgreSQL/SQL Server）或CROSS APPLY（SQL Server）实现每行驱动一次子查询 - 更通用的做法是先
JOIN再用应用层或窗口函数去重/分组
硬要在 SELECT 里塞多行子查询，多数数据库直接报错，别试。
相关子查询被误写成非相关子查询导致意外多行
容易忽略的是子查询是否“相关”。例如：SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'active') 是非相关子查询，只执行一次；但若漏了关联条件，本意是“每个订单对应用户的活跃状态”，却写成 WHERE status = 'active'（没连到外层 orders），就会返回所有活跃用户 ID，造成逻辑错位。
检查点：
- 相关子查询必须包含对外层表的引用（如
users.id = orders.user_id） - 相关子查询在逻辑上应随外层每一行重新执行，结果自然可能是单行或多行，取决于数据
- 用
EXPLAIN看执行计划，确认子查询是否被标记为DEPENDENT SUBQUERY（MySQL）或SubPlan（PostgreSQL）
多行问题的根因往往不在“怎么压成一行”，而在于没想清楚：这里到底该是一对一、一对多，还是多对多关系。先厘清语义，再选语法。
