DISTINCT不能修复“子查询返回多行”错误，因为它仅去重不减行数；若业务本就存在多值事实（如一用户多日志），加DISTINCT仍报错，须改用IN、聚合函数或JOIN等符合语义的方案。
为什么 DISTINCT 不能直接修复“子查询返回超过1行”
DISTINCT 不是“取一行”的开关，它只对结果去重，不控制行数。比如 SELECT DISTINCT name FROM users WHERE dept_id = 123 返回 5 个不同姓名，加了 DISTINCT 还是 5 行——标量子查询上下文仍会报错。
它真正起作用的场景是：数据本该唯一，但因 JOIN 膨胀或关联条件缺失导致重复（例如用户表和订单表没加 ON u.id = o.user_id 就直接 JOIN）。这时应先修正逻辑，而不是靠 DISTINCT 掩盖。
- 误用示例：
(SELECT DISTINCT id FROM logs WHERE user_id = u.id)—— 若一个用户有 3 条日志，仍返回 3 行 -
DISTINCT后仍报错，说明业务上存在多值事实，不是显示问题 - 检查是否漏了关键筛选条件（如时间范围、状态字段）
用 LIMIT 1 要小心哪些副作用
LIMIT 1 能压成单行，但代价是牺牲确定性与语义清晰度。数据库不保证哪一行被选中，除非显式加 ORDER BY。
- 无
ORDER BY的LIMIT 1在不同执行、不同 MySQL 版本、甚至同一查询多次运行中可能返回不同结果 - 若业务需要“最新一条”，必须写
ORDER BY created_at DESC LIMIT 1；只写LIMIT 1是在埋坑 - 用在
UPDATE或INSERT ... SELECT中时，隐式随机取值可能导致数据不一致 - 某些数据库（如 PostgreSQL）要求
LIMIT必须配合ORDER BY才允许出现在子查询中
什么时候该换 IN 而不是硬塞 =
当子查询天然可能返回多值，且主查询意图是“匹配集合中的任意一个”，= 就是错的语法选择，必须改用 IN。
- 典型错误写法：
WHERE status = (SELECT status FROM audit_log WHERE event_id = 123)—— 如果 audit_log 里 event_id=123 有 3 条记录，就爆错 - 正确改法：
WHERE status IN (SELECT status FROM audit_log WHERE event_id = 123) -
IN对 NULL 敏感：若子查询返回NULL，整条判断变为UNKNOWN，可能意外过滤掉数据 - 更健壮的替代是
EXISTS，尤其在外层表小、内层表大时性能更好，且不依赖值本身
聚合函数不是万能解药，要看业务是否允许
MAX()、MIN()、COUNT() 等能强制单值，但前提是“取最大/最小/数量”符合业务逻辑。
- 查“用户所属公司名”，
(SELECT MAX(CORP_NAME) FROM corp_info WHERE key = u.corp_key)可能返回字典序最大的名字，而非注册名或主名称 - 更新语句中用
MAX()填充字段，容易掩盖数据建模缺陷（比如一个CORP_KEY对应多个CORP_NAME，说明缺少主标识或状态字段） - 若业务真需要“唯一标识”，应优先检查源表约束（如唯一索引）、补全关联条件，而不是在查询层妥协
- 对时间类字段，
MAX(created_at)比MAX(id)更贴近“最新”语义
最常被忽略的一点：这个错误往往不是 SQL 写错了，而是外键关系松散、历史数据冗余、或业务规则未落地到 schema 层。修复前先确认——那“多行”，到底是脏数据，还是本就该如此？
