GROUP BY后加自关联低效因需两次扫描，而ROW_NUMBER() OVER可避免行压缩、保留明细行并精准标记每组首行。
为什么GROUP BY后加自关联是常见但低效的解法
想查“每个用户的最新订单+用户姓名”，很多人会先GROUP BY user_id算出MAX(created_at)，再用子查询或JOIN把订单表拉回来取完整字段。这本质是两次扫描：一次分组聚合，一次关联回查。数据量一上来，执行计划里常出现Nested Loop或Hash Join，IO和CPU都吃紧。
用ROW_NUMBER() OVER替代自关联的关键写法
核心不是“去掉GROUP BY”，而是绕过它对行数的压缩——窗口函数保留原始行，只加逻辑标记。
-
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY created_at DESC, id DESC)必须显式写ORDER BY，否则PostgreSQL报错、MySQL结果不稳定 - 时间字段精度不足（如只有秒级）时，
id DESC补位能保证排序唯一，避免LAG()或差值计算失效 - 别在
SELECT里混用GROUP BY和窗口函数，比如SELECT user_id, COUNT(*) OVER(PARTITION BY user_id), SUM(amount) FROM orders GROUP BY user_id——COUNT(*)没加OVER就变成全表计数，语义错乱
哪些自关联场景能被一个OVER直接干掉
前提是单表、分组边界清晰、计算依赖明细行粒度。
- 找每组第一条：
ROW_NUMBER() OVER (PARTITION BY category ORDER BY score DESC)+WHERE rn = 1 - 算环比/差值：
LAG(amount) OVER (PARTITION BY user_id ORDER BY created_at)，不用JOIN上一行 - 统计组内条件数：
COUNT(CASE WHEN status = 'paid' THEN 1 END) OVER (PARTITION BY user_id)，比关联子查询少一次扫描
容易被忽略的性能雷区
多个不同PARTITION BY或ORDER BY的窗口函数共存时，PostgreSQL和SQL Server大概率触发多次排序扫描——比如同时要AVG(price) OVER (PARTITION BY brand)和SUM(sales) OVER (PARTITION BY region ORDER BY date)，引擎无法复用排序结果。
更隐蔽的是OVER ()空括号写法：表面只是加个总行数，但PostgreSQL会隐式全表排序；如果真只需要总数，SELECT COUNT(*) FROM t单独查再JOIN，反而更可控。
