应根据业务意图选择in、exists或关联条件：=要求单值，多行时改用in匹配集合或exists判断存在性；select/set中子查询须通过关联外层字段、聚合函数或order by+limit确保唯一性，distinct和无序limit 1不可靠。

WHERE里用=匹配子查询却返回多行

直接报错 Subquery returns more than 1 row（MySQL）或类似提示，因为 = 要求右边必须是单值。这不是语法错误，是数据库在语义检查阶段就拒绝执行。

先单独执行子查询确认结果，再按业务意图选方案：

• 本意是“属于集合中任意一个” → 改用 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 中必须返回一行一列，否则直接报错，不是警告。

常见原因是漏了外层表关联条件，比如写成：(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')
• 若某 user_id 下无记录，该字段自然为 NULL，符合预期
• 别指望 DISTINCT 救急——它只去重，不减少行数；LIMIT 1 可临时兜底，但无 ORDER BY 就等于随机取，生产环境慎用

UPDATE/DELETE里子查询返回多行

SET 后面必须填一个确定值，不能塞一堆。报错不是语法错，是语义冲突。

最常见原因是子查询没关联外层表字段，变成非相关子查询：

• 错误写法：UPDATE orders SET status = (SELECT name FROM statuses WHERE active = 1) —— 查出所有激活状态名，必然多行
• 修复关键：检查 WHERE 是否含外层字段，如 orders.status_code，并确保它是等值条件
• 真有多行匹配？按业务选：ORDER BY created_at DESC LIMIT 1（取最新）、MAX(name)（聚合）、或改用 JOIN 替代子查询（更稳定、可读性好）

想模糊匹配多个关键词怎么办

LIKE 是标量操作符，右侧不能是多行结果。写成 WHERE name LIKE (SELECT keyword FROM keywords) 必报错。

正确思路不是硬塞，而是转为存在性检查：

• 用 EXISTS + 关联：WHERE EXISTS (SELECT 1 FROM keywords k WHERE users.name LIKE CONCAT('%', k.keyword, '%'))
• 关键词少且固定？拼 OR 链：WHERE name LIKE '%张三%' OR name LIKE '%李四%'
• 避免在子查询里 SELECT * 或不加 WHERE 过滤，防止意外扫全表

最容易被忽略的点：错误常不在子查询本身，而在你没意识到它被放在了标量上下文中。比如存储过程里 SET @x = (SELECT id FROM t WHERE ...)，哪怕平时只返回一行，一旦某天数据异常就崩。从写第一行子查询开始，就得明确它是否必须单值、由谁保证、不满足时怎么兜底。