在复杂业务统计里，嵌套查询是最容易悄悄产生重复记录的地方。比如主表一行对应明细表多行，子查询没做好聚合，外层 SELECT 就会把同一主键拉出好几遍，最终导致 COUNT 或 SUM 结果偏大。很多团队第一反应是在最外层加 DISTINCT，但这往往不是最优解。
一、为什么嵌套查询会出现重复记录
嵌套查询中的重复，绝大多数情况不是数据本身重复，而是关联膨胀。假设我们要查“下过单的用户”，写成子查询 JOIN 订单表，而一个用户有多笔订单，那么用户在结果集里就会出现多次。这种重复是关系型数据库做笛卡尔式展开时的正常行为，但在业务语义上属于冗余。
另一个常见原因是子查询返回了多列，但外层只关心某一列，数据库无法在嵌套层自动合并。例如用 IN 子查询时，内部 SELECT 了带冗余信息的宽行，优化器有时不会主动去做去重推送，就会把重复行带出来。理解这一点，才能决定是在里面消重还是在外面消重。
1.1 用 EXISTS 替代 JOIN 避免展开
如果目的只是“存在即保留”，EXISTS 比 JOIN 更安全。它只要找到一条匹配就返回真，不会把主表行复制成多行。下面这段 PostgreSQL 风格代码展示两种写法差异：
-- 容易产生重复的展开写法 SELECT u.id, u.name FROM users u JOIN orders o ON o.user_id = u.id; -- 用 EXISTS 避免重复 SELECT u.id, u.name FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id );
第一种 JOIN 在用户有三单时就会出三行，第二种 EXISTS 永远最多一行。当外层还要做聚合时，前者必须先 DISTINCT 或 GROUP BY，后者直接干净。
从执行计划看，EXISTS 子查询通常被优化成半连接（Semi Join），扫描到第一条就停止，IO 明显低于 JOIN 后去重。因此在“判断存在”场景，优先改写法比加 DISTINCT 更根本。
二、DISTINCT 真的慢吗？什么时候该用
DISTINCT 本身不慢，慢的是它触发的排序或哈希去重发生在大结果集上。如果重复行已经在嵌套内部被压到很少，外层 DISTINCT 只是收尾，代价极低。反之，先 JOIN 出百万行再 DISTINCT，就要建临时表排序，CPU 和内存都会吃紧。
所以当业务必须同时取主表和子表字段、又无法改 EXISTS 时，可以把 DISTINCT 下推到子查询里，先对小集合去重，再 JOIN。这样外层就是干净的一对一。
2.1 子查询内去重示例
下面演示把去重放在派生表里，缩小参与 JOIN 的行数：
SELECT u.id, u.name, d.last_order_date FROM users u JOIN ( SELECT DISTINCT user_id, MAX(order_date) AS last_order_date FROM orders GROUP BY user_id ) d ON d.user_id = u.id;
这里派生表先按 user_id 聚合并去重，出来的就是每个用户一行。主查询再关联，不会产生倍数膨胀，也不需要外层 DISTINCT。相比直接 JOIN 后 SELECT DISTINCT u.id，临时表规模小了一个数量级。
需要注意，派生表里的 DISTINCT 和 GROUP BY 有点重叠。上面其实 GROUP BY 已保证唯一，DISTINCT 可省略。但如果在子查询里 SELECT 了非分组列且想全局去重，DISTINCT 就有意义。写的时候看执行计划，避免叠床架屋。
三、索引与执行计划配合优化
无论用 EXISTS 还是内层去重，索引决定了数据库能不能快速定位匹配行。对 orders.user_id 建索引，EXISTS 和派生表聚合都能走索引范围扫描，不必全表读。
用 EXPLAIN 看计划时，重点搜“HashAggregate”“Unique”“Semi Join”这些节点。如果出现很大的“Sort”在上面消重，说明 DISTINCT 作用在了大输入上，要考虑改写。
3.1 对比三种方案代价
我们用一张简表总结常见写法特征：
| 方案 | 重复风险 | 典型代价点 | 适用场景 |
|---|---|---|---|
| JOIN 后外层 DISTINCT | 高 | 大结果集排序去重 | 临时报表，懒得改写法 |
| EXISTS 半连接 | 无 | 索引命中即停 | 只判断存在性 |
| 派生表内聚合去重 | 无 | 子查询小表构建 | 需带子表统计字段 |
从表里能看出，把去重动作尽量左移（靠近数据源头）总是划算的。数据库优化器虽聪明，但也不会自动把外层 DISTINCT 重写成半连接，尤其跨视图时。
实际项目中，建议先跑一遍带重复的原始 SQL，用 EXPLAIN ANALYZE 记下行数，再按上面三种方式改写，对比返回行数和耗时。多数情况 EXISTS 或内聚能砍掉九成临时数据。
四、容易踩的坑
有人为了“绝对去重”，在最外层无脑 SELECT DISTINCT 并把所有展示列都塞进去，包括文本大字段。这会导致排序键极宽，磁盘临时文件暴涨。正确做法是只对被业务定义为重复标准的键去重，其他列用聚合或 FIRST_VALUE 取代表值。
还有一类坑是视图嵌套：视图 A 已经 DISTINCT 过，视图 B 套 A 又 JOIN 一次，外层再 DISTINCT。三层去重纯属浪费。遇到这种，拆开视图看底层，把去重合并到最里层即可。
4.1 用窗口函数替代部分去重
如果一定要保留重复中的最新一条，用 ROW_NUMBER 比 DISTINCT 清晰：
SELECT id, name, order_date
FROM (
SELECT u.id, u.name, o.order_date,
ROW_NUMBER() OVER (PARTITION BY u.id ORDER BY o.order_date DESC) AS rn
FROM users u
JOIN orders o ON o.user_id = u.id
) t
WHERE rn = 1;
这段代码在嵌套里给每个用户按时间编号，外层只取第一行，天然无重复。它比 GROUP BY 灵活，能拿任意列，也不会触发额外 DISTINCT 排序。
总结来说，处理嵌套查询重复记录的核心思路是：先问是不是关联膨胀，能改 EXISTS 就改，要带字段就内层聚合，实在不行才外层 DISTINCT，并配好索引与计划核查。这样既能拿到准确数据，也不会让数据库白白排序。
SQL嵌套查询DISTINCT优化重复记录处理修改时间：2026-08-04 05:09:32