应根据业务意图选择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 ...)，哪怕平时只返回一行，一旦某天数据异常就崩。从写第一行子查询开始，就得明确它是否必须单值、由谁保证、不满足时怎么兜底。
