使用=比较子查询会报错，应改用IN或EXISTS；当子查询出现在WHERE中且用于=、!=等比较运算符时，必须确保子查询返回单值，否则需替换为IN（多值匹配）或EXISTS（存在性检查）。
WHERE 中用 = 比较子查询报错，立刻换 IN 或 EXISTS
只要子查询在 WHERE 里被 =、!=、 等标量操作符调用，且返回多行，数据库就拒绝执行——这不是 bug，是语义保护。错误信息通常是 <code>Subquery returns more than 1 row（MySQL）、ORA-01427（Oracle）或 more than one row returned by a subquery（PostgreSQL）。
- 想表达“属于某集合”，无条件优先用
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) - 别用
= ANY替代IN：功能等价但可读性差，且对NULL处理更隐晦；IN遇到子查询全为NULL时明确返回FALSE，而= ANY返回UNKNOWN，可能意外过滤数据
SELECT 列表中子查询爆多行，补关联条件比加 LIMIT 1 可靠
像 (SELECT meta_value FROM user_meta WHERE meta_title = 'user_image') 这种写法没限定 user_id，一查就是全表扫描，多个用户设头像就必然报错。加 DISTINCT 或 LIMIT 1 是临时糊弄，不是修复。
- 正确做法是显式关联外层字段：
(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 允许无序LIMIT，但 SQL Server 直接语法报错
误用聚合函数或 DISTINCT 不能解决根本问题
DISTINCT 不是“变单行”的开关，它只去重，不减少行数。一个用户有 3 条日志，SELECT DISTINCT event_type FROM logs WHERE user_id = 123 仍可能返回 3 行，标量上下文照样崩。
-
MAX()、MIN()、COUNT()能压成单值，但前提是业务逻辑允许——查“最新订单时间”用MAX(created_at)合理，查“用户头像 URL”用MAX(meta_value)就荒谬 - 别把
DISTINCT当兜底：它只在 JOIN 导致重复膨胀时有用（比如主表一行被副表三行匹配），此时应先检查 JOIN 条件是否遗漏，而非硬加DISTINCT - 聚合函数无法还原原始行的上下文（如创建时间、状态），一旦业务需要“最新一条完整记录”，就必须用
ORDER BY ... LIMIT 1，而不是MAX()
真正该优先检查的三个地方
子查询爆多行，大概率不是语法问题，而是数据理解偏差或建模疏漏。
- 子查询的
WHERE条件是否真的能唯一确定一行？有没有漏掉时间范围、租户 ID、状态过滤等关键约束？ - 涉及的表是否存在未预期的 1:N 关系？比如
user_meta表本就允许多条同meta_title记录，那“取头像”就必须靠user_id+meta_title联合定位 - 子查询是否本该是“相关子查询”却写成了“非相关子查询”？例如漏了
users.id = orders.user_id这类外层引用，导致子查询脱离上下文、扫全表
