group by 无法直接生成“其他”分组，因其执行早于聚合排序，必须用窗口函数（如 row_number()）先排序排名，再通过子查询+case when 将前n名保留、其余标为“其他”。
为什么 GROUP BY 不能直接生成“其他”分组
SQL 的 GROUP BY 只能按字段原始值分组，无法在聚合过程中动态判断“是否属于前 N 名”，更不会自动把剩余行归为“其他”。常见错误是试图用 CASE WHEN 硬编码分类，结果漏掉新出现的类别，或把本该进“其他”的低频项单独列出。
核心矛盾在于：分组逻辑依赖聚合结果（如计数排名），但 GROUP BY 执行早于排序和截断。必须分两步走——先算出各组频次和排名，再按排名阈值重映射分组名。
用窗口函数 + 子查询实现“前5名 + 其他”结构
主流方案是嵌套查询：内层用 ROW_NUMBER() 或 RANK() 对分组统计结果排序，外层用 CASE WHEN 将排名 ≤5 的保留原名，其余统一标为“其他”。注意别用 ORDER BY 替代窗口排序——那只是最终输出顺序，不参与分组重映射。
-
ROW_NUMBER() OVER (ORDER BY COUNT(*) DESC)更稳妥，避免相同频次时排名跳跃导致“其他”漏项 - 子查询必须包含所有需要展示的字段（如原分类名、计数），否则外层
CASE无源可依 - MySQL 8.0+、PostgreSQL、SQL Server 2012+ 支持；SQLite 需 3.25+，旧版得用自连接模拟排名
示例（统计用户来源，只显示前3个来源 + “其他”）：
SELECT CASE WHEN rn <h3>UNION ALL 拼接“主要分组”和“其他”时的陷阱</h3> <p>有人倾向用两个独立查询 <code>UNION ALL</code>：一个查前 N 名，一个查剩余总和。这看似直观，但极易出错——两次 <code>GROUP BY</code> 的分组键可能因数据变动不一致，导致“其他”里混入本该上榜的项，或重复计算。</p>
- 必须确保两个子查询基于完全相同的过滤条件（WHERE 子句一字不差）
- “其他”子查询的
WHERE条件要排除主查询已覆盖的所有值，例如用source NOT IN (SELECT source FROM (...) LIMIT 3)，但注意NOT IN遇 NULL 会全失效 - 若主分组依据是表达式（如
SUBSTR(city, 1, 2)），则“其他”子查询也得复现该表达式，不可直接比对原始字段
当“其他”需展开明细时，别在聚合层硬塞
如果业务要求点击“其他”后能查看具体包含哪些 source，就绝不能只在 SELECT 中用 CASE 合并——那样丢失了原始标识。正确做法是保留明细行，在应用层或视图中做二次聚合：先查出所有 source 及其 rn，前端/BI 工具按 rn > N 归类展示，同时缓存 rn > N 的完整列表供钻取。
强行在 SQL 层用 STRING_AGG() 或 GROUP_CONCAT() 把“其他”里的 source 拼成字符串，会导致：无法索引、超长截断、后续难以过滤。这不是归并问题，是展示层级混淆。
真正难处理的是跨多维分组（比如按 region 和 source 联合统计，再各自归并“其他”）。这时窗口函数得加 PARTITION BY，且每个维度的“前 N”需独立计算，容易写成笛卡尔积式错误。这种场景建议拆成多个 CTE，别贪一行解决。
