distinct on 必须严格匹配 order by 前缀字段顺序，否则报错；其结果由 order by 决定首行，非随机；与普通 distinct 语义不同，前者保留分组首行全列，后者仅投影去重；需配合联合索引提升性能。
DISTINCT ON 必须配 ORDER BY，且顺序要严格对齐
不加 ORDER BY 或排序字段顺序/数量与 DISTINCT ON 不一致，PostgreSQL 会直接报错或返回不可靠结果。这不是警告，是硬性语法约束。
-
DISTINCT ON (a, b)要求ORDER BY必须以a, b开头（可追加其他字段，如ORDER BY a, b, c DESC） -
ORDER BY a, c会报错：缺少b；ORDER BY b, a也会报错：顺序不匹配 - 即使数据当前看起来“碰巧有序”，没显式声明
ORDER BY，结果就是未定义的——下次执行可能换一条
想取每组最新/最早记录？靠 ORDER BY 方向控制
DISTINCT ON 本身不决定“最新”还是“最早”，它只保留每组中 ORDER BY 排序后第一条。所以方向必须手动指定。
- 取每个用户最新登录：
ORDER BY user_id, login_time DESC, id DESC（加id DESC防止时间相同时随机选） - 取每个商品最低价：
ORDER BY product_id, price ASC, updated_at DESC - 用
ASC还是DESC取决于业务含义，不是语法偏好
DISTINCT ON 和普通 DISTINCT 的行为差异很关键
很多人误以为 DISTINCT ON (a) 是 “按 a 去重”，其实它是在逻辑分组后挑一行，而普通 DISTINCT a 是投影去重——两者输出列数、语义、性能都不同。
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
-
SELECT DISTINCT name FROM company→ 只返回name列，7 行 -
SELECT DISTINCT ON (name) name, age, salary FROM company→ 返回全部三列，但每name只一行（共 7 行），具体哪行由ORDER BY决定 - 前者等价于
GROUP BY name投影；后者等价于窗口函数中ROW_NUMBER() OVER (PARTITION BY name ORDER BY ...)取 rn=1
索引能显著加速 DISTINCT ON 查询
如果经常按某几列做 DISTINCT ON + ORDER BY，建联合索引几乎总是值得的，否则会触发大量排序和临时磁盘写入。
- 对于
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前缀完全一致，否则优化器大概率不用 - 没有合适索引时，100 万行以上数据的
DISTINCT ON查询可能比等效的ROW_NUMBER()更慢——别迷信语法糖
实际使用中最容易被忽略的，是把 DISTINCT ON 当成“自动智能去重”，而不主动控制 ORDER BY 的完备性和索引适配。它不猜你要什么，只严格执行你写的排序逻辑。
