percentile_cont和percentile_disc必须在聚合前用于原始数据去噪，因聚合已消融离群值；二者分别通过线性插值和取实际值计算分位数，mysql需用窗口函数模拟，iqr法因嵌套深、性能差而少用。
用 PERCENTILE_CONT 或 PERCENTILE_DISC 剔除聚合前的离群值
直接对 GROUP BY 后的结果再做百分位过滤是无效的——因为聚合已把原始行“压缩”成单行，离群值早已被 AVG/MAX/SUM 消融或放大。真正有效的去噪，必须在聚合前就筛掉异常原始记录。
PostgreSQL 和 SQL Server 支持 PERCENTILE_CONT（连续插值）和 PERCENTILE_DISC（取实际存在的值），MySQL 8.0+ 需用窗口函数模拟，而 Hive/Trino 则原生支持 percentile_cont。
- 先算出第 5 百分位和第 95 百分位作为边界：
PERCENTILE_CONT(0.05) WITHIN GROUP (ORDER BY amount) - 再用这些边界过滤原始数据，最后聚合：
WHERE amount BETWEEN ? AND ? - 注意：不能在 HAVING 中引用
PERCENTILE_CONT，它不接受聚合别名，必须嵌套子查询或 CTE
MySQL 8.0+ 中用窗口函数模拟百分位去噪
MySQL 不支持 PERCENTILE_CONT 聚合函数，但可用 ROW_NUMBER() + COUNT(*) 手动逼近。关键不是追求理论精度，而是确保边界稳定、可复现。
- 计算总行数：
COUNT(*) OVER () AS total_cnt - 定位第 5% 位置：
FLOOR(0.05 * total_cnt)，然后用ROW_NUMBER() OVER (ORDER BY amount)匹配该序号 - 更稳妥的做法是用两个 CTE：一个算上下界值，一个用
WHERE amount BETWEEN (SELECT lower_bound) AND (SELECT upper_bound) - 避免在 ORDER BY 中使用 NULL 值字段，否则
ROW_NUMBER()排序不稳定，导致每次执行边界偏移
聚合后仍需二次去噪？警惕逻辑陷阱
如果业务要求“剔除各组中平均值偏差过大的组”，例如“去掉销售额均值高于整体均值 3 倍的部门”，这不是去噪，而是分组筛选——此时应使用 HAVING 或外层 WHERE，而非百分位。
- 错误写法：
HAVING AVG(sales) > PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY AVG(sales))——PERCENTILE_CONT无法作用于聚合结果集 - 正确写法：先 CTE 算出各组
AVG(sales)，再在外层用AVG() OVER()和STDDEV() OVER()构建 Z-score 过滤 - 更常见且安全的替代：用
AVG(sales) > (SELECT AVG(sales) * 3 FROM dept_sales)，显式子查询更可控
为什么不用 IQR 法？兼容性与性能代价
IQR（Q3 − Q1）理论上比百分位更鲁棒，但几乎所有主流 SQL 引擎都不提供直接计算四分位数的内置函数。硬实现需要至少三层嵌套：一层求 Q1/Q3，一层 JOIN 对齐，一层过滤——在千万级表上容易触发临时表溢出或内存超限。
- PostgreSQL 可用
PERCENTILE_CONT(0.25)和PERCENTILE_CONT(0.75)替代，但要注意：它们返回的是标量，不能直接用于窗口场景 - Trino 中
approx_percentile()更快但有误差，线上任务慎用，除非容忍 ±2% 边界漂移 - 真正要兼顾鲁棒与效率，不如前置一步：用
WHERE sales > 0 AND sales 这类业务规则兜底，比纯统计方法更可靠
