mode()不是窗口函数，postgresql 14+仅支持mode() within group（聚合用法），mysql/sql server/oracle/sqlite均无原生众数窗口函数，必须用count()+row_number()模拟实现。
为什么 MODE() 窗口函数在大多数 SQL 引擎里根本不能用
直接说结论：PostgreSQL 从 14 开始支持 MODE() WITHIN GROUP，但它**不支持窗口语法**（即不能跟 OVER (PARTITION BY ...)）；MySQL、SQL Server、Oracle、SQLite 均无原生众数窗口函数。所谓“快速计算分组内众数”，本质是绕过缺失功能，用 COUNT() + ROW_NUMBER() 模拟实现。
用 ROW_NUMBER() + COUNT() 手动找每组出现最多的值
核心思路是：对每个分组内各值计数 → 按计数降序排序 → 取第一条。必须注意排序的确定性，否则同频次值可能每次结果不同。
典型写法（以 PostgreSQL/SQL Server/BigQuery 兼容语法为例）：
SELECT
group_id,
value AS mode_value
FROM (
SELECT
group_id,
value,
ROW_NUMBER() OVER (
PARTITION BY group_id
ORDER BY COUNT(*) DESC, value ASC -- 同频时按 value 升序保稳定
) AS rn
FROM t
GROUP BY group_id, value
) ranked
WHERE rn = 1;
-
GROUP BY group_id, value是必要前置，先聚合出每个组内各值的频次 -
ORDER BY COUNT(*) DESC, value ASC中的value ASC不可省——否则ROW_NUMBER()在频次相同时行为未定义，结果不可复现 - 若需返回原始表每行对应的众数值（即“为每行打上本组众数标签”），得用
JOIN或WINDOW套一层，不能直接在原表上开窗
MySQL 8.0+ 和 SQLite 3.25+ 的特别注意点
MySQL 支持窗口函数但不支持子查询中直接嵌套聚合（如 COUNT() OVER 无法和 GROUP BY 混用），所以必须两层子查询；SQLite 则不支持 WINDOW 子句中的 ORDER BY 与聚合共存，同样要先 GROUP BY 再开窗。
MySQL 安全写法示例：
SELECT group_id, value
FROM (
SELECT group_id, value, cnt,
ROW_NUMBER() OVER (
PARTITION BY group_id
ORDER BY cnt DESC, value ASC
) AS rn
FROM (
SELECT group_id, value, COUNT(*) AS cnt
FROM t
GROUP BY group_id, value
) t1
) t2
WHERE rn = 1;
- 必须拆成两层：内层聚合计数，外层窗口排序取顶
- MySQL 对
value ASC的稳定性更敏感——若value为 NULL，需显式写NULLS FIRST或NULLS LAST（8.0.22+ 支持） - SQLite 不支持
NULLS FIRST/LAST，NULL 默认排最前，若业务中 NULL 是合法取值且需参与众数判断，得提前用COALESCE(value, '___NULL___')转义
性能和边界情况怎么避坑
众数计算天然比均值/最大值慢，因为必须全量分组计数。当某组数据量极大或组数极多时，GROUP BY group_id, value 可能成为瓶颈。
- 确保
(group_id, value)有联合索引，尤其当value基数高时，索引能跳过排序 - 如果只要“近似众数”，可用采样：先
LIMIT随机抽样再统计，但无法保证准确性 - 空组（某
group_id下无数据）不会出现在结果里——若需补零，得用LEFT JOIN原始分组维度表 - 严格来说，众数未必唯一；当前写法只返回一个。若需所有并列众数，把
ROW_NUMBER()换成RANK()，再过滤RANK() = 1
真正麻烦的不是语法，而是确认“你定义的众数是否允许 NULL、是否接受任意一个并列值、是否需要处理空组”——这些业务逻辑决定 SQL 结构，而不是反过来。
