用WHERE过滤异常值再求AVG最常用可控；需先定义业务异常标准，如BETWEEN 1 AND 100或NOT IN (-1,-999,0)，并单独处理NULL。
用 WHERE 过滤掉明显异常的数值再求 AVG
直接在 AVG() 外层加条件是最常用、最可控的方式。比如字段 score 中混入了 0、-999 或超过 100 的脏数据，你得先定义什么是“异常”——这取决于业务逻辑，不是算法自动判断。
常见错误是把过滤逻辑写成 WHERE score != 0 AND score IS NOT NULL，但漏掉了其他非法值（如字符串转成 0、超限录入）。建议先用 SELECT MIN(score), MAX(score), COUNT(*) FROM table 快速探查分布。
- 只保留合理范围：例如
WHERE score BETWEEN 1 AND 100 - 排除已知哨兵值：例如
WHERE score NOT IN (-1, -999, 0)（注意NULL需单独处理） - 组合使用：例如
WHERE score IS NOT NULL AND score > 0 AND score
用 PERCENTILE_CONT 或近似分位数动态剔除离群点
当异常值边界不固定（比如不同班级的分数分布差异大），硬写死 BETWEEN 容易误杀或漏杀。这时可借助窗口函数计算分位数，把落在 [5%, 95%] 区间的值挑出来再平均。
注意：PERCENTILE_CONT 是标准 SQL，但各数据库支持程度不同——PostgreSQL 和 SQL Server 支持完整语法；MySQL 8.0+ 要用 PERCENT_RANK() 搭配子查询模拟；SQLite 不原生支持。
示例（PostgreSQL）：
SELECT AVG(score)
FROM (
SELECT score,
PERCENTILE_CONT(0.05) WITHIN GROUP (ORDER BY score) AS p5,
PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY score) AS p95
FROM exam_results
) t
WHERE score BETWEEN p5 AND p95;
避免用 AVG + CASE WHEN 隐式包含异常值
有人会写 AVG(CASE WHEN score BETWEEN 1 AND 100 THEN score END)，以为这样就过滤了。错——CASE 返回 NULL 时，AVG() 会跳过该行，看似效果一样，但语义模糊、不可读，且容易在嵌套逻辑中出错。
更严重的是：如果 score 是字符串类型，某些数据库（如 MySQL）会在隐式转换时把非数字转成 0，导致 0 被当作有效值参与计算，而你根本没意识到它本该被排除。
- 务必确认字段类型：
SELECT pg_typeof(score) FROM ...（PostgreSQL）或DESCRIBE table（MySQL） - 字符串型数值必须先显式清洗，例如
WHERE score ~ '^[0-9]+\.?[0-9]*$'（PostgreSQL 正则） -
AVG()对空结果集返回NULL，别忘了检查是否真有数据参与计算
性能与精度取舍：TRIMMED_MEAN 并不存在于标准 SQL
Excel 里的 TRIMMED_MEAN 是按比例砍头去尾，SQL 没有内置等价函数。强行模拟（比如用 ROW_NUMBER() 排序后 OFFSET/LIMIT 截断）会导致全表排序，大数据量下极慢，且无法利用索引。
真正要兼顾性能和鲁棒性，推荐两步走：
- 在 ETL 或应用层做一次轻量清洗，把明确非法值设为
NULL或打上is_valid标志位 - 查询时用带索引的布尔字段过滤，例如
WHERE is_valid_score = true
临时分析可以接受子查询或 CTE，但上线 SQL 务必避免对百万级表反复跑 PERCENTILE_CONT ——它本质是排序聚合，代价远高于普通 WHERE。
