嵌套查询中使用DISTINCT会强制物化中间结果，阻碍谓词下推、索引利用和流式处理，导致性能显著下降；应优先用EXISTS、内层DISTINCT或JOIN替代。
嵌套查询里加DISTINCT会强制提前物化中间结果
数据库优化器在处理嵌套查询（比如子查询、CTE 或视图）时，本可下推 WHERE 条件、延迟计算、甚至消除冗余 JOIN。但一旦外层或内层用了 DISTINCT，多数引擎（MySQL、PostgreSQL、SQL Server）就无法安全做这些优化——因为去重必须基于「完整中间结果集」，它得先算出所有行，再排序或哈希，最后筛掉重复。这等于把原本可能流式处理的逻辑，硬生生卡在某个阶段生成临时表。
常见错误现象：EXPLAIN 输出里突然多出 Using temporary 和 Using filesort，哪怕原始子查询本身走的是索引扫描。
- 如果子查询返回 50 万行，但外层只取
LIMIT 10，没DISTINCT时可能只查 10 行就停；加了之后，必须全算完再取前 10 - CTE 被标记为
MATERIALIZED（PostgreSQL）或强制物化（SQL Server），失去内联优化机会 - Oracle 可能因
DISTINCT触发隐式ORDER BY，进一步放大排序开销
DISTINCT字段组合破坏索引下推能力
嵌套结构中，DISTINCT a, b 的语义要求对整个投影结果去重，而优化器很难判断基表上的索引是否“覆盖”这个组合——尤其当嵌套里还混着函数、JOIN 或 COALESCE 等非确定性表达式时。它不敢假设索引顺序天然唯一，只能退回到通用去重路径。
使用场景：你写了一个视图 SELECT DISTINCT status, category FROM orders JOIN users...，然后在外层再 WHERE status = 'active'。理想情况是先过滤再 DISTINCT，但实际执行计划常变成：先 JOIN 出全部，再 DISTINCT，最后 WHERE —— 因为 DISTINCT 阻断了谓词下推。
- 联合索引
(status, category)在纯单表查询中有效，但在嵌套 JOIN 后失效 - 若子查询含
UPPER(name)，即使name有索引，DISTINCT UPPER(name)也无法利用该索引 - MySQL 8.0+ 对 CTE 的
REF访问支持有限，DISTINCT会直接关闭该优化通道
不同数据库对嵌套 DISTINCT 的处理差异很大
不是所有引擎都“老实”执行去重。Oracle 有时会利用 DISTINCT 暗示来切换执行计划（比如改用 HASH UNIQUE 而非 SORT UNIQUE），反而加速；但 MySQL 和旧版 PostgreSQL 基本只会加临时表。这种不确定性让性能更难预测。
参数差异：
- PostgreSQL 的
work_mem直接决定DISTINCT是走内存哈希还是落盘，嵌套多层时极易溢出 - SQL Server 若嵌套查询被当作“不可内联视图”，
DISTINCT会让优化器放弃尝试索引视图匹配 - MySQL 5.7 不支持子查询中
DISTINCT与ORDER BY共存，会报错；8.0 允许但执行计划更保守
性能影响：同一语句在 PostgreSQL 上可能仅慢 2 倍，在 MySQL 上因临时表 I/O 可能慢 10 倍以上。
替代方案比硬扛 DISTINCT 更可靠
嵌套场景下，DISTINCT 很少是唯一解法。真要语义等价去重，优先考虑更可控的替代路径。
可给出简短示例：
-- ❌ 嵌套 + DISTINCT（易失控） SELECT DISTINCT u.id, u.name FROM users u WHERE u.id IN ( SELECT user_id FROM orders WHERE status = 'paid' ); <p>-- ✅ 改用 EXISTS（不触发去重逻辑，且可下推） SELECT u.id, u.name FROM users u WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.user_id = u.id AND o.status = 'paid' );</p><p>-- ✅ 或用主键 JOIN（天然去重，且走索引） SELECT u.id, u.name FROM users u INNER JOIN (SELECT DISTINCT user_id FROM orders WHERE status = 'paid') o ON u.id = o.user_id;
-
EXISTS不产生中间结果集，避免物化开销 - 把
DISTINCT提到最内层子查询（如上面第二个例子），能让优化器更早收束数据量 - 若业务上
orders.user_id本就应唯一，直接建唯一索引比每次查都去重更治本
真正难处理的，是那些嵌套里带聚合、窗口函数、又必须对外暴露去重语义的场景——这时候别省事，拆成两步：先 INSERT INTO 临时表并建索引，再查它。临时表的可控性，远高于嵌套 DISTINCT 的黑盒行为。
