窗口函数能在分组后保留明细行并计算组内排序、排名或聚合，而group by会合并行且order by仅作用于最终结果，无法实现组内排序取top-n等需求。
为什么不能直接用 GROUP BY 配合 ORDER BY 实现分组内排序聚合
因为 GROUP BY 本身不保留组内行序，ORDER BY 在聚合后才生效，对组内数据排序毫无作用。你写 SELECT ..., GROUP_CONCAT(name ORDER BY score DESC) FROM t GROUP BY class 看似可行，但这是 MySQL 特有的非标准语法，且仅限于少数聚合函数（如 GROUP_CONCAT、STRING_AGG），无法通用到取 Top-N、累计求和、前后行比较等场景。
真正可控、可移植的方案是窗口函数——它在分组后、聚合前完成排序与计算，逻辑更清晰，表达力更强。
ROW_NUMBER() 和 RANK() 在分组内排序时的区别必须搞清
两者都依赖 OVER (PARTITION BY ... ORDER BY ...)，但处理并列值的方式不同：
-
ROW_NUMBER()：严格按顺序编号，即使score相同也分配不同序号，比如95, 95, 87→1, 2, 3 -
RANK()：并列则同名，跳过后续名次，95, 95, 87→1, 1, 3 -
DENSE_RANK()：并列同名，不跳号，95, 95, 87→1, 1, 2
选哪个取决于业务定义：“第 1 名有两个，下一个是第 2 名”用 DENSE_RANK()；“下一个是第 3 名”才用 RANK()；若只要取最新一条记录（不管并列），ROW_NUMBER() 最稳妥。
用 FIRST_VALUE / LAST_VALUE 实现分组内极值提取要防坑
FIRST_VALUE(score) OVER (PARTITION BY class ORDER BY score DESC) 看似能取每班最高分，但默认窗口帧是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，导致 FIRST_VALUE 实际只在当前行及之前找最大值，不是全组最大值。
一款AI工具，主要用于使用 Codex CLI 进行深度网络搜索，适用于需要多源综合分析的复杂查询。当 `web_search`（Brave）返回结果不足，或用户……时使用，适合需要提升相关任务效率的用户。
必须显式指定完整帧范围：
FIRST_VALUE(score) OVER ( PARTITION BY class ORDER BY score DESC ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING )
或者更简洁地改用聚合窗口函数：MAX(score) OVER (PARTITION BY class) —— 它天然作用于整个分区，无需手动调帧。
STRING_AGG + ORDER BY 是分组内有序拼接的正确姿势
PostgreSQL 和 SQL Server 支持 STRING_AGG(expr, delimiter ORDER BY ...)，MySQL 8.0+ 用 GROUP_CONCAT(expr ORDER BY ... SEPARATOR ...)，但注意：
- MySQL 的
GROUP_CONCAT默认长度上限是 1024，超长会被截断，需提前设SET SESSION group_concat_max_len = 1000000 - PostgreSQL 的
STRING_AGG不会自动去重，如有重复需先DISTINCT或用子查询预处理 - 若要拼接多字段（如
"name:张三,score:92"），建议在STRING_AGG外层用CONCAT构造，别塞进ORDER BY子句里干扰排序逻辑
窗口函数本身不提供字符串聚合能力，所以这类需求仍得靠聚合函数，只是排序控制权交还给了标准 SQL 语法，不再依赖方言特性。
窗口函数不是银弹——它不减少数据行数，SELECT * 加窗口会返回所有原始行，真要压缩成每组一行，还得配合外层 GROUP BY 或 DISTINCT ON（PostgreSQL）或 QUALIFY（BigQuery / Snowflake）。这点容易被忽略，结果查出几千行以为逻辑错了，其实只是忘了收口。
