使用=比较多行子查询必然报错，应改用in或exists；in适用于多值匹配，语义清晰；exists适用于存在性判断，性能更优且支持索引下推。
直接用 = 去比较一个可能返回多行的子查询，一定会报错——这不是语法写错了，是数据库在拒绝执行一个语义上说不通的操作：它没法拿一个值去“等于”一堆值。
WHERE 中 = (subquery) 报错，优先改用 IN 或 EXISTS
这是最常见也最该立刻修正的写法。比如：
WHERE customer_id = (SELECT id FROM customers WHERE city = 'Shanghai')
只要上海有多个客户，就崩。错误信息可能是 Subquery returns more than 1 row（MySQL）、ORA-01427（Oracle）或 more than one row returned by a subquery（PostgreSQL）。
-
IN是语义最匹配的替代：把上面改成WHERE customer_id IN (SELECT id FROM customers WHERE city = 'Shanghai')，逻辑清晰、可读性强、且天然支持多值 -
EXISTS更适合“是否存在”的判断场景，性能通常更好：比如WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id AND o.status = 'pending')，它不关心具体值，只确认存在性，还能利用索引下推 - 别用
= ANY替代IN——虽然功能等价，但IN更直观、对NULL的行为更可预期；= ANY只在需要>、等比较时才有不可替代性
SELECT 列表里标量子查询多行，补关联条件比加 LIMIT 1 更可靠
典型错误是漏了外层表字段的关联，比如：
(SELECT meta_value FROM user_meta WHERE meta_title = 'avatar')
没限定 user_id，结果扫全表，一有多个用户设头像就报错。
- 正确做法是显式关联：
(SELECT um.meta_value FROM user_meta um WHERE um.user_id = t.user_id AND um.meta_title = 'avatar')，这样每行只查自己对应的记录，结果天然唯一 -
LIMIT 1是兜底手段，不是解决方案：它不保证取哪一行，除非配上ORDER BY；无序LIMIT 1在不同执行、不同版本中可能返回不同值，生产环境慎用 - 如果业务真需要“最新一条”，必须写
ORDER BY created_at DESC LIMIT 1；如果只是想取任意有效值，MAX()或MIN()比LIMIT 1更稳定（尤其在无索引字段上）
误用聚合函数或 DISTINCT 不能解决根本问题
DISTINCT 不是“变单行”的开关——它只去重，不减少行数。比如一个用户有 3 条日志，SELECT DISTINCT event_type FROM logs WHERE user_id = 123 还是可能返回 3 行，标量上下文照样报错。
- 聚合函数如
MAX()、COUNT()确实强制单值，但前提是业务允许：查“最高订单金额”用MAX(amount)合理；查“用户头像 URL”用MAX(url)就可能返回字典序最大的那个，而非注册时设置的那个 - 如果子查询本就该返回多行（比如一用户多地址），那就不是子查询的问题，而是你用了错误的结构——该用
JOIN或LATERAL（PostgreSQL）/APPLY（SQL Server），而不是硬塞进标量位置 - 用
COALESCE((SELECT ...), 'default')可以兜底空结果，但无法解决多行问题
排查和验证：先看子查询本身返回几行
别猜，直接查。定位报错 SQL 后，把子查询单独拎出来跑：
SELECT COUNT(*) FROM (your_subquery) AS t;
如果结果大于 1，说明问题确实在这里。再进一步看数据分布：
- 是否缺少关键过滤条件？比如漏了
status = 'active'或时间范围 - 关联字段是否有重复？比如
user_id和meta_title没建联合索引，或业务上允许多个同名 meta 记录 - 有没有
NULL干扰？特别是用ALL或ANY时，含NULL的子查询会让整个表达式变成UNKNOWN，在WHERE中等效于FALSE，导致意外丢数据
真正容易被忽略的点是：报错往往不是因为 SQL 写得不够“技巧”，而是因为数据模型和查询逻辑没对齐——比如默认认为“每个用户只有一个头像”，但实际业务已允许上传多个。这时候修 SQL 不如先修认知。
