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容易掩盖笛卡尔积问题——先检查是否有多对多关联导致行数异常膨胀
