直接结论：对每个分组内按频次降序排列后用 percent_rank() 计算相对排名，再过滤 pct_rank
用 PERCENT_RANK() 精准定位每个分组的前10%高频值
直接结论：对每个分组内按频次降序排列后用 PERCENT_RANK() 计算相对排名，再过滤 pct_rank ，是唯一能严格表达“前10%”语义的做法。
它不依赖总行数预计算，不强制均分，相同频次的记录自动共享同一排名值——比如两个客户订单量都是 99，它们的 PERCENT_RANK() 完全相等，不会因排序不确定性被拆开。但必须写全 OVER (PARTITION BY group_col ORDER BY freq DESC)，漏掉 PARTITION BY 就变成全表排名，失去“每个分组”的前提。
- 错误示范：
PERCENT_RANK() OVER (ORDER BY freq DESC)→ 所有组混在一起排，结果完全错 - 注意 NULL 处理：
freq字段若有 NULL，ORDER BY freq DESC默认把 NULL 排最前（PostgreSQL/SQL Server），可能把空值顶进前10%，需显式加NULLS LAST（如支持）或提前过滤 - MySQL 8.0+、PostgreSQL、SQL Server 支持；SQLite 和旧版 MySQL（
为什么不能用 NTILE(10) 替代
NTILE(10) 是把每个分组的记录**强行切成 10 段**，每段行数最多差 1，但第一段占比未必是 10%。例如某分组共 13 条记录，NTILE(10) 分配为 2,2,1,1,...，第一段占 2/13 ≈ 15.4%；若只有 7 条，则第一段必为 1 条 → 占比 14.3%。它适合“大致分层”，不适合“精确取前10%”。
- 更隐蔽的问题：
NTILE()不保证同频次记录落在同一组，排序字段相同时可能被随机拆散 - 写法上容易漏
ORDER BY：只写NTILE(10) OVER (PARTITION BY group_col)而不加ORDER BY freq DESC，结果不可控 - 即便加了
ORDER BY，它也只解决“怎么切”，不解决“切得准不准”——百分比失真就是设计使然
旧版 MySQL 或 SQLite 怎么办
没有窗口函数时，只能靠子查询+变量或应用层兜底。最可行的是先算出各分组目标行数，再用 ROW_NUMBER() 截断：
SELECT group_col, item, freq
FROM (
SELECT
group_col, item, freq,
ROW_NUMBER() OVER (PARTITION BY group_col ORDER BY freq DESC, item ASC) AS rn,
CEILING(cnt * 0.1) AS target_n
FROM (
SELECT group_col, item, COUNT(*) AS freq
FROM source_table
GROUP BY group_col, item
) t1
JOIN (
SELECT group_col, COUNT(*) AS cnt
FROM (
SELECT group_col, item, COUNT(*) AS freq
FROM source_table
GROUP BY group_col, item
) t2
GROUP BY group_col
) t3 USING (group_col)
) t4
WHERE rn
-
CEILING()确保至少取 1 行（避免FLOOR()在小分组下返回 0） - 二级排序
item ASC消除同频次下的不确定性，否则ROW_NUMBER()结果可能每次执行都不同 - 性能隐患明显：两次 GROUP BY + JOIN + 窗口函数，数据量大时建议加复合索引
(group_col, item)
高频值统计本身容易卡在哪
真正拖慢查询的往往不是“取前10%”这一步，而是前面的频次聚合。如果原始表没索引、或 GROUP BY 字段基数极高（比如用户ID），COUNT(*) 阶段就会吃满内存甚至落盘。
- 先确认是否真需要“每个分组中前10%”，还是只需全局前10%高频项——后者可省掉
PARTITION BY，大幅降低复杂度 -
COUNT(*)必须走索引：在 MySQL 中，确保group_col和分组依据字段上有联合索引；PostgreSQL 可考虑部分索引过滤无效数据 - 若只是临时分析，且允许近似结果，可用 HyperLogLog 类算法（如 PostgreSQL 的
HLL扩展）先估总数，再抽样计算，跳过全量聚合
百分比类统计最危险的地方在于：逻辑看似简单，但只要数据分布不均、分组大小差异大、或排序字段存在大量重复，PERCENT_RANK() 和 NTILE() 的输出就可能和业务直觉严重偏离——别只看前几行结果对不对，一定要用 COUNT(*) 验证每个分组实际返回了多少行。
