不能用MAX()/MIN()直接排除异常值，因其仅返回单个极值，不支持跳过、排序定位或条件过滤；强行嵌套子查询易误删多值或漏判离群点，可靠做法是先用WHERE按阈值、分位数或IQR过滤，再聚合。
直接用 WHERE 过滤掉异常值，比在聚合函数里“排除”更可靠、更可控。 MAX() 和 MIN() 本身没有“排除第 N 大/小”的内置逻辑，强行用它们处理异常值容易误伤正常数据，或根本达不到目的。
为什么不能用 MAX()/MIN() 直接“排除异常值”
MAX() 和 MIN() 只返回单个极值，不提供排序位置、不支持跳过前 N 个、也不接受条件过滤。你无法写成 MAX(price EXCEPT OUTLIER) 或 MIN(score IGNORE TOP 1)——这些语法不存在。
常见错误是试图用子查询嵌套绕过，比如：
SELECT MAX(price) FROM products WHERE price <p>这看似“去掉一个最大值”，但问题很多：</p>
- 如果存在多个相同最大值（如 999 出现 3 次），
会把全部 999 都干掉，结果可能远低于预期 - 如果第二高是 998，而真实异常值其实是 9999（离群严重），这个写法完全识别不出
- 无法同时排除最大和最小两个方向的异常值
真正有效的三种排除方式
核心思路：先定义“什么是异常值”，再用对应机制过滤，最后才聚合。
-
基于固定阈值过滤：最简单直接。例如价格超过 10000 或低于 0 明显不合理，就加
WHERE price BETWEEN 0 AND 10000再算MAX()/MIN() -
基于分位数动态过滤（推荐）：用窗口函数计算
PERCENT_RANK()或NTILE(100)，剔除 top 1% 和 bottom 1%：SELECT MAX(price), MIN(price) FROM (SELECT price, PERCENT_RANK() OVER (ORDER BY price) pr FROM sales) t WHERE pr BETWEEN 0.01 AND 0.99 -
基于 IQR（四分位距）规则：需两层子查询算出 Q1/Q3，再过滤：
WHERE price >= q1 - 1.5*(q3-q1) AND price ，其中q1和q3来自PERCENTILE_CONT(0.25)等（PostgreSQL/SQL Server 支持；MySQL 8.0+ 需用窗口模拟）
GROUP BY 场景下排除每组的异常值
若要“每个 category 中分别去掉最高最低各一个再求平均”，不能依赖 GROUP BY + MAX() 组合——那只是查出极值，不是剔除后聚合。
正确做法是用窗口函数标记每组内的排序位置：
SELECT category, AVG(price) AS avg_clean<br>FROM (<br> SELECT *,<br> ROW_NUMBER() OVER (PARTITION BY category ORDER BY price DESC) rn_desc,<br> ROW_NUMBER() OVER (PARTITION BY category ORDER BY price ASC) rn_asc<br> FROM products<br>) t<br>WHERE rn_desc > 1 AND rn_asc > 1<br>GROUP BY category;
注意点：
-
ROW_NUMBER()保证每组内唯一编号，适合“去掉一个最大+一个最小” - 若想去掉所有并列极值（如三个 999 都算异常），改用
RANK()并配合> 1判断 - MySQL 5.7 不支持窗口函数，只能用关联子查询 + LIMIT，但性能差且无法安全去多行
最容易被忽略的是：异常值判定逻辑必须和业务对齐。用 PERCENT_RANK() 剔除 1%，在数据量少于 100 行时可能一个都不删；而固定阈值在业务规则变化时又容易失效。没有银弹，得看你的数据分布和运维成本怎么权衡。
