= 比较子查询报错时应改用 in 或 exists：in 用于匹配多个值，exists 用于判断存在性；子查询多行需补关联条件，limit 1 非解决方案，须配合 order by 或聚合函数；distinct 不解决多行问题，需先定位数据逻辑原因。
WHERE 中用 = 比较子查询，报错就换 IN 或 EXISTS
错误现象是 MySQL 报 Subquery returns more than 1 row，PostgreSQL 报 more than one row returned by a subquery used as an expression——这不是语法写错了，是数据库在拒绝执行一个语义矛盾的操作：你让一个值去“等于”一堆值。
- 如果本意是“匹配多个可能的值”，立刻把
=改成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 列表里子查询多行，补关联条件，别碰 LIMIT 1
典型错误是写成 (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') - 这样每行只查自己对应的记录，结果天然唯一；若无匹配，自动返回
NULL，符合预期 -
LIMIT 1是兜底手段，不是解决方案：无ORDER BY时结果不可预测，不同执行、不同版本可能返回不同值
真要取最新/最大/任意一行？ORDER BY + LIMIT 或聚合函数必须带业务含义
不能只写 LIMIT 1 就完事。数据库不保证哪条被选中，随机取值等于埋坑。
- 查“最新一条”，必须写
ORDER BY created_at DESC LIMIT 1（MySQL/PostgreSQL）或ORDER BY created_at DESC OFFSET 0 ROWS FETCH FIRST 1 ROW ONLY（标准 SQL） - SQL Server 强制要求子查询里用
TOP 1必须配ORDER BY，否则语法报错 - 如果业务允许“取最大值”，用
MAX()比LIMIT 1更稳定，尤其字段无索引时
别把 DISTINCT 当救急开关，它不减少行数
DISTINCT 只去重，不减行。一个用户有 3 条不同头像记录，SELECT DISTINCT meta_value FROM user_meta WHERE user_id = 123 还是可能返回 3 行——标量上下文照样报错。
-
DISTINCT有效的前提是：逻辑上本该唯一，但因 JOIN 膨胀导致重复 - 它不是“取任意一行”的快捷键，也不是多行问题的通用解
- 误加
DISTINCT只会让问题更难定位，掩盖真实的数据关联缺失
IN 或 EXISTS，后者必须补上 WHERE 里的外键约束。
