子查询返回多行导致报错时，应根据业务意图选择IN、EXISTS或关联条件；标量上下文中必须确保单值返回，避免用LIMIT 1兜底而忽视排序与业务逻辑。
直接报错说明你用了单值比较符（=、!=、、>）去接一个本该返回多行的子查询——这不是语法错误，是数据库在拒绝执行一个逻辑矛盾的操作。
WHERE 中用 = 比较子查询报错，立刻换 IN 或 EXISTS
错误现象是 MySQL 报 Subquery returns more than 1 row，PostgreSQL 报 more than one row returned by a subquery used as an expression。本质是你让一个字段“等于”一堆值，数据库没法选。
- 如果本意是“匹配多个可能的值”，把
=改成IN：WHERE status IN (SELECT status FROM audit_log WHERE event_id = 123) - 如果本意是“只要存在就满足”，改用
EXISTS更准更快：WHERE EXISTS (SELECT 1 FROM audit_log WHERE event_id = 123 AND status = t.status) -
IN遇到子查询返回NULL会整体判为UNKNOWN，可能漏数据；EXISTS不受NULL影响，语义更干净
SELECT 列表里子查询返回多行，必须补关联条件
典型错误是写成 (SELECT meta_value FROM user_meta WHERE meta_title = 'user_image')——没限定 user_id，一查就是全表扫描，多个用户设了头像就崩。
- 正确做法是显式关联外层字段：
(SELECT um.meta_value FROM user_meta um WHERE um.user_id = team_request.user_id AND um.meta_title = 'user_image') - 这样每行只查自己对应的记录，结果天然唯一；若无匹配，自动返回
NULL，符合预期 -
LIMIT 1是兜底手段，不是解决方案：无ORDER BY时结果不可预测，不同执行、不同版本可能返回不同值
真要取“最新/最大/任意一行”，必须带业务含义的排序或聚合
查“最新一条”，必须写 ORDER BY created_at DESC LIMIT 1（MySQL/PostgreSQL），或标准 SQL 的 ORDER BY created_at DESC OFFSET 0 ROWS FETCH FIRST 1 ROW ONLY。
- SQL Server 强制要求子查询里用
TOP 1必须配ORDER BY，否则语法报错 - 如果业务允许“取最大值”，用
MAX()比LIMIT 1更稳定，尤其字段无索引时 -
DISTINCT不解决多行问题：DISTINCT只去重，不减行。一个用户有 3 条不同头像记录，SELECT DISTINCT meta_value FROM user_meta WHERE user_id = 123还是可能返回 3 行——标量上下文照样报错
排查时先单独执行子查询，再看业务意图是否匹配
别猜，直接复制子查询部分单独运行，确认它到底返回几行、有没有 NULL、字段是否可为空。
- 如果子查询本身返回空，外层
=会变成UNKNOWN，整行被过滤——你可能根本没意识到它会空 - 相关子查询中所有对外部表的引用必须带外层表别名，且该别名必须在子查询外层定义
- 用
EXPLAIN看执行计划，若显示DEPENDENT SUBQUERY，说明有相关子查询，此时更要核对字段来源是否准确
最常被忽略的是：子查询返回多行不是“技术问题”，而是“数据逻辑没想清楚”。先问自己一句：这一行到底该和哪一条匹配？这个“哪一条”，必须由业务规则定义，不能靠数据库随机挑。
