根本原因是DISTINCT作用于外层结果集，而内层子查询已因JOIN、非主键字段或并列子查询产生逻辑冗余；EXISTS通过半连接避免行膨胀，GROUP BY配合窗口函数可精准控制去重逻辑。
为什么嵌套查询里加了 DISTINCT 还有重复？
根本原因不是 DISTINCT 没起作用，而是它作用在了错误的层级上。嵌套查询中，外层 SELECT 的 DISTINCT 只对最终结果集去重，而内层子查询可能已生成逻辑冗余数据（比如一对多关联未收敛），导致外层即使加了 DISTINCT，仍因字段组合实际不同而保留多行。
常见诱因包括：
- 子查询中用了
JOIN但没控制主表唯一性（例如用订单表 JOIN 订单项表，却按订单 ID 查询用户信息） - 子查询返回了非主键字段（如含时间戳、状态变更记录等自然不唯一的列）
- 多个子查询并列使用（
SELECT (SELECT ...), (SELECT ...) FROM ...），各子查询独立执行，无法协同去重
EXISTS 替代 IN 子查询能避免重复吗？
不能直接避免重复，但能从语义上规避“一对多膨胀”。IN 子查询若返回重复值（如 SELECT user_id FROM logs WHERE type='login'），数据库通常会自动去重；但若外层主表本身存在重复关联路径，IN 仍可能因执行计划展开为多次匹配而放大结果。
EXISTS 更安全，因为它是半连接（semi-join）：只关心“是否存在”，不拉取子查询的任何字段，天然不引入额外行。实操建议：
- 把
WHERE id IN (SELECT user_id FROM events)改成WHERE EXISTS (SELECT 1 FROM events WHERE events.user_id = users.id) - 确保子查询中的关联条件有索引（如
events.user_id），否则EXISTS可能比IN更慢 - 不要在
EXISTS子查询里写SELECT *——用SELECT 1或SELECT NULL即可，语义清晰且部分数据库会做轻量优化
用 GROUP BY 替代 DISTINCT 的实际效果
当你要去重的字段组合恰好是某张表的主键或业务唯一键时，GROUP BY 和 DISTINCT 效果一致；但一旦涉及聚合计算（比如要取每个用户的最新订单时间），GROUP BY 是唯一可行路径，而 DISTINCT 完全无能为力。
关键差异在于可控性：
-
DISTINCT是黑盒去重，你无法指定“保留哪一行”（数据库按内部顺序任选） -
GROUP BY配合MAX()/MIN()/ROW_NUMBER()等，可以明确控制保留逻辑（例如ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)） - 某些数据库（如 MySQL 5.7 严格模式）要求
SELECT中所有非聚合字段必须出现在GROUP BY列表中，否则报错ONLY_FULL_GROUP_BY
窗口函数 + QUALIFY（BigQuery/Trino）或子查询过滤是最稳的去重方式
当你需要“每个分组取最新/最早/任意一行”，硬靠 DISTINCT 或 GROUP BY 往往要拼接字符串或依赖不确定行为。现代 SQL 引擎提供了更干净的解法：
在 BigQuery 中：
SELECT user_id, order_id, created_at FROM orders QUALIFY ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) = 1
在 PostgreSQL / MySQL 8.0+ 中，得用子查询：
SELECT user_id, order_id, created_at
FROM (
SELECT user_id, order_id, created_at,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC) AS rn
FROM orders
) t
WHERE rn = 1
注意点：
-
ROW_NUMBER()保证每组编号唯一，RANK()和DENSE_RANK()在遇到相同排序值时会并列，可能导致去重失败 - 如果业务允许“任取一行”，用
ROW_NUMBER() OVER (PARTITION BY x ORDER BY RANDOM())（PostgreSQL）或ORDER BY RAND()（MySQL）更高效 - 嵌套层级变深后，别忘了给中间结果加索引——尤其是
PARTITION BY和ORDER BY的字段组合
真正容易被忽略的是：去重逻辑是否该下推到子查询里。很多时候，问题不在外层怎么写 DISTINCT，而在内层是否已经用 GROUP BY 或 EXISTS 收敛了数据源头。先想清楚“重复从哪来”，再决定在哪去。
