先说一个很多人都踩过的坑:PostgreSQL 的 DISTINCT ON 并不是让你字段变得唯一,而是按你指定的字段分组,每组只返回 ORDER BY 排序后的第一整行。结果合不合预期,全看后面那条 ORDER BY 写得够不够严谨——很多开发者在前期没摸清这个规则,后面查数据时翻车,还找不着原因
先说一个很多人都踩过的坑:PostgreSQL 的 DISTINCT ON 并不是让你字段变得唯一,而是按你指定的字段分组,每组只返回 ORDER BY 排序后的第一整行。结果合不合预期,全看后面那条 ORDER BY 写得够不够严谨——很多开发者在前期没摸清这个规则,后面查数据时翻车,还找不着原因。
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 (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 会触发大量排序操作,甚至把数据写进磁盘临时文件,性能瞬间崩塌:
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 前缀完全一致,否则优化器大概率不会用索引ROW_NUMBER() 快 20–80%;无索引时反而更慢,甚至被 ROW_NUMBER() 反超最容易被忽略的一点:千万别把 DISTINCT ON 当成“自动智能去重”。它不会猜你要最新还是最早,也不会自动保证稳定性——你写的 ORDER BY 缺一个字段、少一个方向、没建索引,结果就可能下次执行就变,完全不符合可靠业务的预期。

侠游戏发布此文仅为了传递信息,不代表侠游戏网站认同其观点或证实其描述