标量子查询返回多行时应根据业务意图选择in、exists或关联条件修正：where中用=需改in或exists；select列表中须补外层字段关联；取最新行必须order by+limit，不可仅用limit 1。
标量子查询被放在了要求单值的上下文中，但实际返回了 ≥2 行——数据库直接拒绝执行，不是运行时报错，是语法语义检查阶段就拦下来了。
WHERE 中用了 = 却返回多行？立刻换 IN 或 EXISTS
比如写 WHERE status = (SELECT status FROM audit_log WHERE event_id = 123)，而 audit_log 里 event_id = 123 对应 3 条记录，MySQL 就抛 Subquery returns more than 1 row。
- 本意是“status 属于这些值中的任意一个” → 改用
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 列表里的子查询爆多行？补关联条件，别碰 DISTINCT
像 (SELECT meta_value FROM user_meta WHERE meta_title = 'user_image') 这种写法，没限定 user_id，就会扫全表——加 DISTINCT 也救不了，它只去重，不减行数。
- 正确做法是把外层主表字段带进去：
(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只在“本该唯一、但因 JOIN 膨胀重复”时有用，不是多行救急开关
真要取一行（如最新记录）？ORDER BY + LIMIT/TOP 是硬要求
用 LIMIT 1（MySQL/PostgreSQL）或 TOP 1（SQL Server）本身没错，但无序取值等于随机取值——数据库不保证哪条被选中。
- 查“最新一条”，必须写
ORDER BY created_at DESC LIMIT 1；只写LIMIT 1是留坑 - SQL Server 强制要求子查询里用
TOP 1必须配ORDER BY，否则语法报错 - PostgreSQL 允许无序
LIMIT，但结果不可复现，上线前务必确认业务是否接受不确定性
最容易被忽略的是：错误常不在子查询本身，而在你没意识到它被放在了标量上下文中。比如在存储过程里写 SET @x = (SELECT id FROM t WHERE ...)，哪怕平时只返回一行，一旦某天数据异常就崩。别等报错才加防护，从写第一行子查询开始，就该明确它是否必须单值、由谁保证、不满足时怎么兜底。
