子查询中JOIN未收敛主表唯一性是重复问题最隐蔽源头；需检查JOIN右表键是否唯一，优先用GROUP BY或DISTINCT压平维度，避免依赖外层DISTINCT救火。
子查询里用了JOIN但没收敛主表唯一性
这是最隐蔽也最常被忽略的源头。比如写 SELECT u.name, (SELECT COUNT(*) FROM orders o WHERE o.user_id = u.id) FROM users u 看似安全，但如果把子查询改成 SELECT COUNT(*) FROM orders o JOIN order_items oi ON o.id = oi.order_id WHERE o.user_id = u.id，一对多关联就立刻生效——一个用户有 3 笔订单、每单 2 条明细，子查询内部就先膨胀成 6 行，COUNT(*) 算出来是 6，不是 3。
关键点在于：子查询不是“原子操作”，只要它自己内部存在一对多路径，结果就会被逻辑放大，外层根本无法感知。
- 检查子查询是否含 JOIN，尤其右表是否有重复关联键（如
order_items.order_id非唯一） - 若必须 JOIN，优先在子查询内用
GROUP BY或DISTINCT先压平维度，例如SELECT COUNT(*) FROM (SELECT DISTINCT o.id FROM orders o JOIN order_items oi ON o.id = oi.order_id WHERE o.user_id = u.id) t - 别依赖外层
DISTINCT救火——它只作用于最终输出字段组合，对子查询内部膨胀无能为力
多个并列子查询导致字段组合天然不唯一
像 SELECT id, (SELECT name FROM departments WHERE id = u.dept_id), (SELECT COUNT(*) FROM logs WHERE user_id = u.id) FROM users u 这种写法，两个子查询独立执行，各自返回一行，但外层没有主键约束或去重逻辑，一旦用户表本身有重复 id（比如测试数据未清理），或者某个子查询因 NULL 返回空值导致隐式补行，整行组合就可能意外重复。
更危险的是：数据库对这种写法的优化程度差异很大，MySQL 可能物化子查询，PostgreSQL 可能重写为 LATERAL，行为不可控。
- 避免在 SELECT 列表中并列多个标量子查询，尤其当主表存在潜在重复时
- 改用 LEFT JOIN 预聚合子表，例如先
SELECT user_id, COUNT(*) AS log_cnt FROM logs GROUP BY user_id，再 JOIN 回主表 - 如果必须用子查询，确保其返回值严格单行（加
LIMIT 1或用MAX()/MIN()包裹），并验证 NULL 处理逻辑
子查询返回非主键字段引发组合爆炸
当你写 SELECT u.id, (SELECT created_at FROM orders WHERE user_id = u.id ORDER BY created_at DESC LIMIT 1) FROM users u，看起来只取时间，没问题。但若换成 (SELECT * FROM orders WHERE user_id = u.id ORDER BY created_at DESC LIMIT 1)，哪怕只有一条记录，只要 orders 表里有 updated_at、status 等易变字段，不同时间点查出的整行就可能不同——外层结果看似重复用户 ID，实则是不同订单快照。
本质是：子查询返回的“行”不是抽象概念，而是具体字段值的组合；只要任意字段值不同，整行就不重复，DISTINCT 也拦不住。
- 永远明确子查询要返回什么：是单一标量？还是完整业务实体？前者用聚合函数或标量子查询，后者必须用窗口函数+过滤
- 若需完整记录，直接用
ROW_NUMBER()替代LIMIT 1，例如(SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn FROM orders) t WHERE t.user_id = u.id AND t.rn = 1) - 警惕时间类字段（
created_at、updated_at）、状态类字段（status、version）参与组合，它们天然不具备稳定性
EXISTS/IN 子查询没防住 NULL，导致逻辑错乱
SELECT * FROM users WHERE id IN (SELECT user_id FROM orders) 看起来天衣无缝，但只要 orders.user_id 里有一个 NULL，整个 IN 表达式就返回 UNKNOWN，这行用户直接消失——不是重复，是漏查。而 NOT IN 更致命：SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders)，只要子查询结果含一个 NULL，整条语句返回空集。
这不是性能问题，是 SQL 三值逻辑的硬规则。很多人误以为“重复没处理好”，其实是根本没查到数据。
- 一律改用
EXISTS替代IN做存在性判断：WHERE EXISTS (SELECT 1 FROM orders WHERE orders.user_id = users.id) -
EXISTS不比较值，只看是否存在匹配行，天然绕过NULL陷阱 - 子查询里写
SELECT 1而非SELECT *，语义清晰且部分引擎会跳过字段解析
真正麻烦的从来不是“怎么去重”，而是“为什么会有这些行”。子查询里的重复，往往暴露的是底层数据模型或关联逻辑的松散——比如缺少唯一约束、历史脏数据未清理、ETL 任务重复跑批。查完 SQL，顺手跑一遍 SELECT user_id, COUNT(<em>) FROM orders GROUP BY user_id HAVING COUNT(</em>) > 1，比加十个 DISTINCT 都管用。
