SQL 中 DISTINCT 的去重逻辑

sql的DISTINCT按整行去重，非单列；NULL被视为相同值；ORDER BY字段须出现在select中；无法指定保留哪行，替代方案为GROUP BY或窗口函数。

SQL 的 DISTINCT 是按行去重，不是按列

很多人误以为 DISTINCT 是对某个字段单独去重，其实它作用于整个 SELECT 结果行。只要两行在所有被选中的列上完全一致，才会被合并为一行。

比如 SELECT DISTINCT name, age FROM users，不会只看 name 去重，而是看 (name, age) 这个组合是否重复。哪怕 name 相同但 age 不同，也会保留两条记录。

• 如果只想按 name 取唯一值，应写成 SELECT DISTINCT name FROM users
• 若还想要对应某条记录的 age（比如最新/最小），不能靠 DISTINCT 实现，得用 GROUP BY 或窗口函数
• DISTINCT 会在执行末期触发排序或哈希去重，可能影响性能，尤其在大数据集 + 多列场景下

NULL 在 DISTINCT 中被视为相同值

SQL 标准规定：所有 NULL 在去重时被认为是相等的。也就是说，多行中若某列全为 NULL，它们会被当作重复行合并。

例如：SELECT DISTINCT status FROM orders，若表中有 5 行 status 是 NULL，结果里只会出现一个 NULL。

• 这和 WHERE status = NULL 不同（后者永远不成立），但 DISTINCT 对 NULL 的处理是确定且一致的
• 某些数据库（如 postgresql）允许 DISTINCT ON (col) 语法，可控制保留哪一行，但标准 SQL 不支持
• 如果业务上需要区分“未填”和“明确为空”，建议用字符串标记（如 'UNKNOWN'）代替 NULL

DISTINCT 和 ORDER BY 的配合有隐含约束

当使用 ORDER BY 时，排序字段必须出现在 SELECT 列表中——前提是用了 DISTINCT。否则多数数据库（如 PostgreSQL、SQL Server）会报错；mysql 8.0+ 也默认启用该检查。

错误示例：SELECT DISTINCT name FROM users ORDER BY created_at → 报错，因为 created_at 没出现在 SELECT 中。

• 修复方式：要么把 created_at 加进 SELECT（但会改变去重粒度），要么改用 GROUP BY name ORDER BY MAX(created_at)
• 这个限制的本质是：去重后原始行已不可追溯，ORDER BY 无法安全地基于未选中的列排序
• MySQL 5.7 及更早版本允许这种写法（依赖 sql_mode 设置），但行为不可靠，不建议依赖

替代 DISTINCT 的常见场景与陷阱

真正想“取每组第一条”时，DISTINCT 往往不是正确工具。它不保证返回哪一条，也不支持指定优先级。

比如“每个部门取薪资最高的人”，写成 SELECT DISTINCT dept, MAX(salary) FROM emp GROUP BY dept 是对的；但若写成 SELECT DISTINCT dept, name, salary FROM emp ORDER BY salary DESC，结果既不确定，也无法保证 name 和 MAX(salary) 匹配。

• 需要关联完整行信息时，优先考虑 GROUP BY + 聚合函数，或 ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)
• DISTINCT 无法跳过某些列参与去重（比如忽略时间戳只按业务主键去重），此时必须用子查询或 CTE 预处理
• 在 JOIN 后使用 DISTINCT 容易掩盖笛卡尔积问题——先检查是否有多对多关联导致行数异常膨胀

实际用的时候，最常被忽略的是：DISTINCT 的语义边界完全由 SELECT 子句决定，它不理解业务主键，也不承诺稳定性。一旦涉及“取代表行”或“带条件去重”，就得换思路。