推荐用 PERCENT_RANK() 计算组内归一化排名并过滤 0.05–0.95 区间，需配合 PARTITION BY 和 ORDER BY；必须用 CTE 或子查询实现行级过滤后再聚合，不可与 GROUP BY 混用。
怎么用 PERCENT_RANK() 或 NTILE() 标记极端值
分组后排除最高/最低的 5% 数据，本质是先算每组内各值的相对排名，再按阈值过滤。推荐用 PERCENT_RANK() ——它返回 [0, 1) 区间内的归一化排名（最小值为 0，最大值趋近但不等于 1），比 NTILE(20) 更精确，尤其当组内行数不能被整除时不会偏移。
注意：PERCENT_RANK() 是按排序顺序计算的，必须配合 ORDER BY 子句；且窗口定义中 PARTITION BY 要写清楚分组字段，否则全表当一组算，结果就错了。
- 错误写法：
PERCENT_RANK() OVER (ORDER BY score)→ 缺少PARTITION BY group_id，跨组混排 - 正确写法：
PERCENT_RANK() OVER (PARTITION BY group_id ORDER BY score) - 若想排除最高 5% 和最低 5%，保留中间 90%，条件应为：
prk BETWEEN 0.05 AND 0.95
为什么不能直接在 GROUP BY 后用 HAVING 过滤极端值
HAVING 只能过滤分组聚合后的结果（如 COUNT(*) > 10），无法对组内原始行做逐行筛选。你想“先剔掉每组的异常值，再对剩余行求平均”，这属于行级过滤 + 聚合两阶段操作，必须靠窗口函数完成中间标记。
常见误操作：把 PERCENT_RANK() 当普通聚合函数塞进 SELECT 里，却不加 WHERE 或子查询过滤，导致统计仍含极端值。
- 错：直接
SELECT group_id, AVG(score) FROM t GROUP BY group_id→ 完全没过滤 - 错：在
GROUP BY查询里写PERCENT_RANK() OVER (...) AS prk→ 语法报错，窗口函数不能和聚合混用在同一层 - 对：用子查询或 CTE 先加
prk字段，再WHERE prk BETWEEN 0.05 AND 0.95，最后外层GROUP BY
实际 SQL 写法：CTE + 窗口 + 外层聚合
这是最清晰、兼容性好的写法（PostgreSQL / SQL Server / Oracle / BigQuery 均支持；MySQL 8.0+ 也支持）。避免嵌套过深，用 CTE 拆解逻辑：
WITH ranked AS (
SELECT
group_id,
score,
PERCENT_RANK() OVER (PARTITION BY group_id ORDER BY score) AS prk
FROM scores
)
SELECT
group_id,
AVG(score) AS avg_cleaned
FROM ranked
WHERE prk BETWEEN 0.05 AND 0.95
GROUP BY group_id;
如果数据库不支持 CTE（如旧版 MySQL），可用内联视图替代，但需注意别名必须显式声明；另外，ORDER BY 方向影响高低端判断——升序时 prk=0 是最小值，降序则相反，别反了。
性能和边界情况要注意什么
窗口函数本身不改数据量，但加了 WHERE 后会减少后续聚合的数据规模。真正影响性能的是 PARTITION BY 字段的基数和排序字段的索引情况。若 group_id 分组极多（如百万级），或 score 列无索引，ORDER BY 开销会明显上升。
- 空值处理：
NULL默认排在最前（升序）或最后（降序），可能被误判为极端值。建议提前用WHERE score IS NOT NULL过滤 - 并列值问题：
PERCENT_RANK()对相同score返回相同排名，可能导致实际剔除比例略高于设定（比如一堆并列最高分全被踢出） - 小样本风险：某组只有 3 行，
prk只能取 0、0.5、1，BETWEEN 0.05 AND 0.95会保留全部——这种组不适合用分位数法，得换STDDEV或 IQR
分位数过滤看着简单，但分组粒度、空值、并列、样本量四个点任一个没兜住，结果就偏了。动手前先 SELECT * 看一眼 prk 分布，比硬跑聚合更省时间。
