distinct在子查询中常无效，因其仅作用于子查询自身结果集，而外层in/exists等操作不依赖重复与否；真正生效场景是子查询作为派生表被外层select distinct显式引用。
为什么 DISTINCT 在子查询里没起作用？
因为 DISTINCT 只作用于它所在那一层的 SELECT 结果集，如果子查询被用作表达式（比如在 WHERE ... IN (subquery) 或 SELECT (subquery) 中），它的去重结果不会“透出”到外层逻辑里——外层根本看不到重复与否，只拿到值或布尔判断结果。
常见错误写法：SELECT name FROM users WHERE id IN (SELECT DISTINCT user_id FROM logs)
这里 DISTINCT 确实去重了 user_id，但外层 IN 本身就不关心重复；真正出问题的是当子查询被当作标量子查询（返回单值）却可能返回多行时，会直接报错：Subquery returns more than 1 row。
- 子查询用于
IN、EXISTS、= ANY()等集合操作时，DISTINCT对外层行为无影响，仅减少传输/计算量 - 子查询用于标量上下文（如
SELECT (SELECT ...)）时，必须保证最多一行一列，DISTINCT无法解决“多行”问题，得靠LIMIT 1或聚合函数 - MySQL 8.0+ 和 PostgreSQL 支持
ROW_NUMBER()等窗口函数，但不能直接用在标量子查询中替代DISTINCT
DISTINCT 能用在哪种子查询结构里才真正生效？
只有当子查询是独立的派生表（derived table）或 CTE，并且外层显式引用其结果列时，DISTINCT 才会影响最终输出。例如：
SELECT DISTINCT dept FROM ( SELECT dept FROM employees UNION ALL SELECT dept FROM interns ) AS t;
这里 DISTINCT 作用于外层 SELECT，不是子查询内部——但子查询本身若含重复，会导致中间结果膨胀，拖慢性能。
- 把去重逻辑放到最外层
SELECT DISTINCT，比在每层子查询里加DISTINCT更清晰、更易维护 - 如果子查询是
JOIN的右表，且关联键不唯一，先用GROUP BY或DISTINCT ON（PostgreSQL）预处理，比依赖外层DISTINCT更高效 - SQL Server 中，
APPLY子查询不支持DISTINCT直接修饰，需包装成 CTE 或内联视图
替代 DISTINCT 的实际方案：什么时候该用 GROUP BY 或 EXISTS？
多数情况下，想“消除重复”本质是想表达“存在性”或“取一条代表”，DISTINCT 是最粗糙的工具。比如查“有登录记录的用户姓名”：
- 用
IN+ 子查询：SELECT name FROM users WHERE id IN (SELECT user_id FROM logins)—— 自动去重语义，无需DISTINCT - 用
EXISTS：SELECT name FROM users u WHERE EXISTS (SELECT 1 FROM logins l WHERE l.user_id = u.id)—— 更快，不关心重复，也不怕空值 - 真要取最新一条记录：
SELECT DISTINCT ON (user_id) * FROM logins ORDER BY user_id, created_at DESC（PostgreSQL）或 MySQL 8.0+ 的ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC)
注意：GROUP BY 在子查询中常比 DISTINCT 更明确——例如 SELECT user_id, MAX(created_at) FROM logins GROUP BY user_id，既去重又带聚合信息，避免外层再处理。
容易被忽略的 NULL 和类型隐式转换陷阱
DISTINCT 把所有 NULL 视为相同值，这在子查询中容易引发意外合并。例如：
SELECT DISTINCT category FROM products WHERE status = 'active';
如果 category 有大量 NULL，它们会被压缩成一行，但外层若用这个结果做 JOIN，可能漏掉多条 NULL 记录。
- MySQL 中
CONCAT('a', NULL)返回NULL，导致DISTINCT CONCAT(...)意外合并 - PostgreSQL 对字符串和数字混合比较更严格，
SELECT DISTINCT '1', 1会报错，而 MySQL 会隐式转成数字再比较 - 使用
COALESCE(col, 'unknown')替代裸列参与DISTINCT，可控制NULL的归并行为
真正麻烦的从来不是语法对不对，而是你默认去重的那列，在业务语义里到底允不允许“合并”。
