postgresql 14+ 的 mode() within group 是强制要求 order by 的有序集聚合表达式，仅返回一个众数（并列时取排序首值），不支持窗口用法，全 null 组返回 null。
SQL 标准里确实定义了 MODE()，但绝大多数数据库至今没实现它——不是不会，是优先级低、语义模糊、场景少。你写 MODE(column)，几乎一定报错。
PostgreSQL 14+ 的 MODE() WITHIN GROUP 是什么？
它不是“众数函数”，而是一个带排序约束的聚合表达式，语法强制要求 WITHIN GROUP (ORDER BY ...)。它只返回一个值，即使多个值并列最高频，也只取 ORDER BY 排序后第一个。
OpenCLI Tool Integration
下载
一款AI开发辅助工具，主要用于使用 OpenCLI 工具，可从各类网站及桌面应用中提取数据、下载媒体内容、控制外部 CLI 工具。支持 Bilibili、知乎、小红书、Twitter/X、Reddit、YouTube、Boss直聘、即刻、微博等 30+ 个平台，以及 Cursor、Codex、ChatGPT、Notion 等桌面应用。当用户需要：从社...，适合需要提升相关任务效率的用户。
-
MODE()不能单独用，也不能跟OVER ()窗口语法混用；写成MODE() OVER (PARTITION BY x)直接语法错误 - 全
NULL分组会返回NULL，不报错但容易漏判；含NULL时，GROUP BY默认把所有NULL归为一组，业务上通常要加WHERE column IS NOT NULL - 排序字段必须支持比较（如
text、integer），不能是json或bytea
MySQL / SQL Server / SQLite 怎么办？
没有原生 MODE()，只能靠两层聚合：先分组计频次，再从结果里挑最高频的那个值。核心限制是——MAX(COUNT(*)) 合法性为零，所有数据库都会报 ERROR: aggregate function calls cannot be nested。
- 安全写法必须是子查询嵌套或窗口函数：内层
GROUP BY group_col, value_col算出每个组合的COUNT(*)，外层对这个结果集排序/限制 - MySQL 8.0+ 和 PostgreSQL 可用
ROW_NUMBER() OVER (PARTITION BY group_col ORDER BY COUNT(*) DESC, value_col ASC)，value_col ASC不可省，否则同频时结果不可复现 - SQLite 3.25+ 支持窗口函数，但旧版本只能用相关子查询，性能差且易写错；典型陷阱是子查询里漏掉
WHERE关联条件，导致逻辑变成全局统计
为什么 RANK() 比 ROW_NUMBER() 更贴近“众数”本意？
因为真实业务中，多个值并列最高频很常见（比如两个产品在某区域销量都是 12 单）。ROW_NUMBER() 强制编号，只返回一个，且无法预测是哪一个；RANK() 对同频值赋予相同名次，WHERE rn = 1 就能自然返回全部并列众数。
- 但要注意：如果用
LIMIT 1或TOP 1收尾，哪怕前面用了RANK()，也会人为截断，只留一个 -
FIRST_VALUE()看似简洁，但它依赖窗口排序的确定性，若ORDER BY没写全（比如只写COUNT(*) DESC没加第二排序键），结果可能每次都不一样 - 真正麻烦的不是语法，而是“众数”在 SQL 里没有唯一定义：是否允许
NULL参与？是否必须返回全部并列值？这些得由业务规则定，SQL 只负责执行
