先说一个很多人都踩过的坑：PostgreSQL 的 DISTINCT ON 并不是让你字段变得唯一，而是按你指定的字段分组，每组只返回 ORDER BY 排序后的第一整行。结果合不合预期，全看后面那条 ORDER BY 写得够不够严谨——很多开发者在前期没摸清这个规则，后面查数据时翻车，还找不着原因。
为什么加了 DISTINCT ON 还报错？
PostgreSQL 会直截了当地拒绝执行，只要 ORDER BY 不满足前缀匹配规则。这不是警告，是硬性语法约束——完全不给商量余地：
DISTINCT ON (user_id, status)要求ORDER BY必须以user_id, status开头（顺序、数量、表达式必须完全一致）ORDER BY user_id, created_at DESC→ 报错：缺少statusORDER BY status, user_id→ 报错：顺序颠倒ORDER BY user_id, status, created_at DESC→ 合法，而且推荐这么写：多一个排序字段能有效避免时间相同时结果随机的问题
DISTINCT ON 和普通 DISTINCT 的行为差异很关键
不少人以为 DISTINCT ON (a) 等价于“按 a 去重”，但实际情况完全不同。普通 DISTINCT 只返回你列出的那一列本身；而 DISTINCT ON 保留的是整行，只是从每组里面挑出 ORDER BY 排序的第一条。咱们看两个例子：
SELECT DISTINCT name FROM company→ 输出只有name列，假如有 7 个不同名字，就返回 7 行SELECT DISTINCT ON (name) name, age, salary FROM company→ 输出三列，仍然是 7 行，但每个name具体对应哪条age/salary，完全由ORDER BY name, salary DESC决定- 前者本质上等价于
GROUP BY name投影；后者则等价于窗口函数ROW_NUMBER() OVER (PARTITION BY name ORDER BY salary DESC)再取rn = 1
没有索引时 DISTINCT ON 可能比 ROW_NUMBER() 还慢
别看到语法糖就往上贴。数据量一大、索引没配好，DISTINCT ON 会触发大量排序操作，甚至把数据写进磁盘临时文件，性能瞬间崩塌：
- 高频查询比如
SELECT DISTINCT ON (user_id) * FROM events ORDER BY user_id, created_at DESC，必须配上联合索引：CREATE INDEX idx_events_user_created ON events (user_id, created_at DESC) - 索引列顺序必须和
DISTINCT ON+ORDER BY前缀完全一致，否则优化器大概率不会用索引 - 实测 1000 万行数据下，有合适索引时 DISTINCT ON 比
ROW_NUMBER()快 20–80%；无索引时反而更慢，甚至被ROW_NUMBER()反超
最容易被忽略的一点：千万别把 DISTINCT ON 当成“自动智能去重”。它不会猜你要最新还是最早，也不会自动保证稳定性——你写的 ORDER BY 缺一个字段、少一个方向、没建索引，结果就可能下次执行就变，完全不符合可靠业务的预期。
