DISTINCT在子查询中无效，除非明确其作用层级；常见错误是套层后未控制外层逻辑或掩盖JOIN膨胀问题，真正需按语义选择COUNT(DISTINCT)、GROUP BY或窗口函数。
DISTINCT 在子查询里加了也没用，除非你明确它作用在哪一层
很多人写 SELECT COUNT(*) FROM (SELECT DISTINCT user_id FROM orders)，以为这样能“先去重再统计”，逻辑没错，但容易忽略两个现实问题：一是子查询里 DISTINCT 确实生效，但外层没做任何限制，结果和 COUNT(DISTINCT user_id) FROM orders 完全等价，还多套一层；二是如果子查询本身含 JOIN 或多表关联，DISTINCT 往往掩盖了连接膨胀的真实问题，不是去重，是硬压。
为什么嵌套 + DISTINCT 常常白忙一场
常见错误现象：
- 写
SELECT * FROM (SELECT DISTINCT a, b FROM t1 JOIN t2 ON ...) AS sub，结果行数还是爆炸——因为DISTINCT是在 JOIN 后对整行去重，而 JOIN 产生的重复组合本就该被业务逻辑提前控制 - 子查询里用了
SELECT DISTINCT id, name, created_at，但外层要的是“每个 name 最新一条”，DISTINCT根本不认created_at的大小关系，只看三者是否完全一致 - 把
DISTINCT放在子查询里，却忘了外层SELECT还带了其他字段（比如加了个ROW_NUMBER()别名），导致外层结果又变重复
真正该做的，是把去重意图拆清楚：
- 如果目标只是“统计不重复用户数”，直接用
COUNT(DISTINCT user_id)，别套子查询 - 如果子查询目的是为后续 JOIN 提供干净的主键集（比如“所有下过单的用户ID”），那
SELECT DISTINCT user_id FROM orders没问题，但必须确保外层 JOIN 条件精准，避免反向放大 - 如果子查询输出要带非去重字段（如用户姓名、最新订单时间），
DISTINCT不适用，得换窗口函数或GROUP BY+ 聚合
什么时候嵌套 + DISTINCT 真有用
典型场景是“预过滤后再参与复杂逻辑”，且子查询结果本身不依赖排序或行级选择。比如：
- 构造一个去重后的标签列表，用于
IN或EXISTS：WHERE tag IN (SELECT DISTINCT tag FROM event_log WHERE dt >= '2026-05-01') - 生成唯一维度值用于
LEFT JOIN，避免因重复键导致笛卡尔积：LEFT JOIN (SELECT DISTINCT category FROM products) cat ON p.category = cat.category - 配合
UNION做跨源归一化：(SELECT DISTINCT id FROM source_a) UNION (SELECT DISTINCT id FROM source_b)，这时DISTINCT在子查询里能减少合并前的数据量
注意：这些场景里，DISTINCT 的价值是缩小中间结果集，不是解决语义去重。
嵌套中用 DISTINCT 的性能陷阱
DISTINCT 在子查询里不会自动下推优化，数据库通常会先执行完整子查询、再做去重，内存/临时磁盘开销照旧。尤其当子查询含大表 JOIN 或函数表达式时：
- 子查询里写了
UPPER(name)或DATE(created_at)，DISTINCT就无法走索引，全表扫描+哈希去重跑不掉 - MySQL 5.7+ 严格模式下，子查询若含未聚合的非
GROUP BY字段，可能直接报错，DISTINCT不能绕过这个限制 - PostgreSQL 允许
DISTINCT ON (col)，但只在顶层SELECT有效，子查询里不支持——别指望靠它实现“每组取一行”
更稳的做法是：把去重逻辑前置到数据源头（比如物化中间表加唯一索引），或者用 CTE 显式命名步骤，方便调试和优化。
最常被忽略的一点：嵌套里加 DISTINCT 后，外层如果还要 ORDER BY 或 LIMIT，必须确认排序字段是否在子查询的 SELECT 列表里——否则 PostgreSQL 和 MySQL 8.0+ 会直接拒绝，不是警告，是报错。
