应根据业务意图选择IN、EXISTS、关联子查询或ORDER BY+LIMIT等正确语法，而非简单加LIMIT 1；子查询多行错误主因是缺失筛选条件或语义不匹配。
直接加 LIMIT 1 或 TOP 1 能让语句不报错，但大概率埋下数据逻辑错误——它不解决“为什么返回多行”，只掩盖问题。真正要做的，是判断业务意图，再选匹配的语法。
子查询在 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') -
DISTINCT只去重，不减行数；它只在“本该唯一、但因 JOIN 膨胀重复”时有用，不是多行救急开关 - 如果某
user_id下真没user_image记录，这个写法自然返回NULL，符合预期
真需要取一行（如最新记录）？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，但结果不可复现，上线前务必确认业务是否接受不确定性
聚合函数不是万能解药，得看业务是否允许“统计值”
MAX()、MIN()、COUNT() 确实能压成单行，但前提是“取最大/最小/数量”符合业务逻辑。
- 查“用户公司名”，写
(SELECT MAX(CORP_NAME) FROM corp_info WHERE key = u.corp_key)可能返回字典序最大的名字，而非注册名——这就不对 - 查“订单总数”，
(SELECT COUNT(*) FROM orders WHERE user_id = u.id)是合理用法 -
COUNT(column)会忽略NULL，COUNT(*)不忽略，选错会导致计数偏差
最常被跳过的动作，是检查子查询是否漏了关键筛选条件：时间范围、状态字段、租户 ID、软删除标记……这些看似次要的 WHERE 子句，往往才是让结果从“多行”变“单行”的关键。别急着改语法，先问一句：这里本该只有一条吗？
