DISTINCT作用于SELECT结果集整体，不参与WHERE过滤逻辑，也不支持按指定列去重；需将分组维度字段显式包含在SELECT中，否则无法实现业务要求的去重效果。
DISTINCT 在 WHERE 子句后加条件为什么没效果
因为 DISTINCT 作用于整个 SELECT 列表，不是对某列单独去重，更不参与 WHERE 的逻辑判断。你写 SELECT DISTINCT name FROM users WHERE status = 'active'，是先过滤出 active 用户，再对结果里的 name 去重；但如果你误以为“加了 WHERE 就能控制去重粒度”，就容易漏掉关键约束。
常见错误现象：DISTINCT 返回的行数比预期多，比如明明只想要每个部门一个负责人，却返回了多个同名的人——因为没把 department_id 一起选出来，DISTINCT 只看到名字重复，但实际是不同部门的同名员工。
- 想按某个维度去重，必须把该维度字段显式包含在
SELECT中，否则DISTINCT无法识别“同一组” - 如果业务上要“每个 department_id 取一条最新记录”，
DISTINCT本身做不到，得换ROW_NUMBER()或子查询 - MySQL 8.0+ 和 PostgreSQL 支持
DISTINCT ON (col)（PostgreSQL）或窗口函数替代方案，但标准 SQL 不支持
ORDER BY 和 DISTINCT 一起用时排序失效
DISTINCT 会隐式触发去重前的无序扫描，而 ORDER BY 是在去重后排序。这意味着：如果你写 SELECT DISTINCT name FROM users ORDER BY created_at DESC，数据库会报错（如 PostgreSQL）或忽略 ORDER BY 字段（如旧版 MySQL），因为 created_at 没出现在 SELECT 列表里。
使用场景：你想取每个用户最近一次登录的设备型号，但只想要型号列表，且按时间倒序排列。
- 必须把排序字段也放进
SELECT，再用外层查询去掉它：SELECT DISTINCT name FROM (SELECT name, created_at FROM users ORDER BY created_at DESC) t - 但注意：这个写法在 MySQL 中可能被优化掉
ORDER BY，实际顺序不可靠；PostgreSQL 要求子查询带LIMIT才允许排序生效 - 更稳的做法是用
GROUP BY name ORDER BY MAX(created_at) DESC，前提是聚合逻辑合理
大量数据下 DISTINCT 性能突然变差
本质是数据库要对结果集做全量哈希或排序去重，内存不够时会落盘，IO 成瓶颈。尤其当 SELECT DISTINCT * 或多列组合去重时，体积和比较成本指数上升。
性能影响明显的情况：千万级用户表查 DISTINCT country, city, district，响应从毫秒级跳到分钟级。
- 避免
DISTINCT *，只选真正需要去重的列 - 检查是否有对应组合索引，例如
(country, city, district)可加速排序去重过程（MySQL 的 Loose Index Scan 在某些场景适用） - 如果只是校验“是否存在重复”，用
EXISTS (SELECT 1 FROM t GROUP BY a, b HAVING COUNT(*) > 1)比SELECT DISTINCT快得多 - PostgreSQL 中可考虑
UNIQUE INDEX配合ON CONFLICT控制源头，而不是反复去重查询
NULL 值在 DISTINCT 中到底算不算重复
标准 SQL 规定：所有 NULL 值彼此相等，所以 SELECT DISTINCT col FROM t 中，不管有多少个 NULL，只返回一个 NULL。但这是语义上的“相等”，不是值比较意义上的相等——这也是最容易混淆的点。
容易踩的坑：你用 COUNT(DISTINCT col) 统计非空唯一值，却发现结果比手动 COUNT(*) FROM (SELECT DISTINCT col FROM t WHERE col IS NOT NULL) 少 1，就是因为前者把 NULL 算进去了，后者没算。
-
COUNT(DISTINCT col)包含一个NULL计数，除非你明确WHERE col IS NOT NULL - 联合去重时，
(1, NULL)和(1, NULL)被视为相同，但(1, NULL)和(1, 'a')当然不同 - 如果业务上
NULL表示“未知”，而你希望它们不参与去重逻辑，就得提前用COALESCE(col, '_MISSING_')替换
去重从来不是加个 DISTINCT 就完事，关键是理解它操作的是最终投影结果集，而不是原始行；很多“奇怪结果”其实都源于没意识到这一点。
