应使用CASE WHEN将异常值映射为NULL，使AVG、SUM等聚合函数自动跳过；WHERE过滤会整行剔除，破坏分组完整性，而CASE WHEN可在保留分组前提下实现组内条件聚合。
聚合函数本身不能“忽略”值，但你可以用 CASE WHEN 把异常值映射为 NULL，让 AVG、SUM、COUNT 等自动跳过它——这是最直接、最兼容的写法。
为什么不能直接 WHERE 过滤？
因为 WHERE 是行级过滤，删掉整行；而“忽略异常值做聚合”通常要求：该行仍参与分组（比如按部门分组），只是它的某个字段（如 salary）不参与当前聚合计算。例如统计每个部门的平均薪资，但想排除明显录入错误的 salary > 1000000 记录——这些记录还在，只是不拉低/拉高均值。
- 用
WHERE salary → 会丢掉整行，该员工的其他字段（如入职时间、职级）也彻底消失，无法用于其他聚合或关联 - 用
CASE WHEN salary BETWEEN 5000 AND 80000 THEN salary END→ 只让异常值变NULL，AVG()自动忽略NULL，其余字段照常参与分组和别的计算
聚合内嵌 CASE WHEN 的标准写法
核心是：在聚合函数内部包裹 CASE WHEN，且所有分支返回类型一致（推荐统一为数值或统一为字符串），并显式写 ELSE NULL 防意外。
AVG(CASE WHEN salary > 0 AND salary —— 安全，显式处理边界-
COUNT(CASE WHEN status = 'active' THEN 1 END)—— 统计 active 数量，非 active 行不计入（等价于COUNT(*) FILTER (WHERE status = 'active')，但兼容性更好） - 别写
CASE WHEN ... THEN salary ELSE 0 END→ 0 会被算进AVG，结果失真 - 别漏
END，否则报错：syntax error at or near "THEN"
多条件 + 多聚合时容易踩的坑
一个查询里同时处理多个异常逻辑（比如薪资异常、工龄异常、金额异常），最容易出错的是类型混用和逻辑重叠。
- 所有
CASE的THEN返回值必须同类型：别让一个分支返回'N/A'（字符串），另一个返回0（数字） - 条件顺序影响结果：如果写
WHEN salary > 10000 THEN 'high'和WHEN salary > 5000 THEN 'mid'，前者会拦截后者——把范围宽的放后面，或用BETWEEN明确区间 - 需要同时统计“清洗后均值”和“原始总数”，就分开写：
AVG(CASE ... END)和COUNT(*)，不要试图在一个CASE里塞两个聚合
性能与索引注意事项
这种写法本质是表达式计算，数据库无法直接走原字段索引。大数据量时：
- PostgreSQL 可建表达式索引：
CREATE INDEX idx_salary_clean ON emp ((CASE WHEN salary BETWEEN 5000 AND 80000 THEN salary END)); - MySQL 8.0+ 支持函数索引，语法类似；但 MySQL 5.7 不支持，只能靠覆盖索引或物化中间结果
- 如果异常值比例极高（比如 90% 都要被
NULL掉），先WHERE过滤主干数据，再在子查询里用CASE做精细清洗，比全表扫更快
真正难的不是写对语法，而是界定“什么是异常值”——业务规则一变，CASE 条件就得同步改，而且得确保所有引用该聚合的地方（报表、下游视图、BI 查询）都用了同一套逻辑，否则统计口径就裂开了。
