在做成绩统计、比赛打分或者商品评分分析时，直接对全部数据求平均分往往不够公平。假设一场比赛有五个评委打分，其中一个评委打出了异常高的分数，整体平均分就会被拉高。常见的处理办法是去掉一个最高分和一个最低分，再对剩余数据求平均。这个需求用SQL实现并不复杂，但里面有不少细节值得推敲，比如极值有并列时怎么处理、数据量大了怎么优化。下面我们结合具体例子把这个问题讲透。
准备测试数据：一张评委打分表
为了让后面的示例有据可依，先建一张打分表并插入一些测试数据。表结构设计得很简单，包含选手编号、评委编号和分数三个字段。
-- 创建打分表
CREATE TABLE scores (
player_id INT, -- 选手编号
judge_id INT, -- 评委编号
score DECIMAL(5,2) -- 分数
);
-- 插入测试数据
INSERT INTO scores (player_id, judge_id, score) VALUES
(1, 101, 9.8),
(1, 102, 9.5),
(1, 103, 9.2),
(1, 104, 8.9),
(1, 105, 6.0),
(2, 201, 9.0),
(2, 202, 8.8),
(2, 203, 8.5),
(2, 204, 8.2),
(2, 205, 7.9);从数据可以看出，选手1的6.0分明显偏低，选手2的分数分布比较均匀。如果不剔除极值，选手1的平均分约等于8.68，被那个6.0分拖累了不少。按照比赛规则去掉最高分和最低分后，结果会更能反映真实水平。
经典方案：子查询结合NOT IN剔除极值
最直观的思路是先用子查询找出每个选手的最高分和最低分，然后在外层查询中把这些分数排除掉，最后对剩余数据求平均。写法如下：
SELECT
player_id,
AVG(score) AS avg_score,
COUNT(*) AS valid_count
FROM scores s
WHERE score NOT IN (
SELECT MAX(score) FROM scores WHERE player_id = s.player_id
UNION ALL
SELECT MIN(score) FROM scores WHERE player_id = s.player_id
)
GROUP BY player_id;这段SQL的关键在于关联子查询。外层的WHERE条件里，子查询通过player_id = s.player_id与外层记录关联，分别取出该选手的最高分和最低分，用UNION ALL合并成一个待排除的分数集合。凡是命中这个集合的记录都会被过滤掉，剩下的记录参与AVG计算。
这种写法的优点是逻辑清晰，几乎所有主流数据库都能直接跑。缺点是关联子查询会对每一行数据执行一次内部查询，当打分记录达到几十万条时性能会明显下降。另外要注意NOT IN的一个坑：如果子查询结果中出现NULL，整个过滤条件会失效。虽然本例中MAX和MIN不会返回NULL（只要分组内有数据），但养成防御意识总是好的。
处理并列分数：ROW_NUMBER比NOT IN更可靠
上面方案有一个隐藏问题：如果某位选手有两个评委都打了最高分，NOT IN会把两条记录全部剔除，导致去掉的分数比预期多。更稳妥的做法是借助窗口函数，给每个选手的分数排序编号，只剔除排序后的一头一尾各一条记录。
SELECT
player_id,
AVG(score) AS avg_score,
COUNT(*) AS valid_count
FROM (
SELECT
player_id,
score,
ROW_NUMBER() OVER (PARTITION BY player_id ORDER BY score DESC) AS rn_high,
ROW_NUMBER() OVER (PARTITION BY player_id ORDER BY score ASC) AS rn_low,
COUNT(*) OVER (PARTITION BY player_id) AS total_cnt
FROM scores
) t
WHERE rn_high > 1
AND rn_low > 1
AND total_cnt > 2
GROUP BY player_id;</p>先在子查询中用ROW_NUMBER按分数降序和升序各编一次号。降序编号为1的就是最高分那条，升序编号为1的就是最低分那条，外层条件rn_high > 1 AND rn_low > 1保证同一条记录不会因为既是最高又是最低（比如该选手只有一条记录）而被误删两次。最后的total_cnt > 2是防御性条件，当选手的打分记录不超过两条时不做剔除，避免把数据全部过滤光。
窗口函数方案的优势在于语义精确：不管最高分有几个评委并列，都只剔除一条。MySQL从8.0版本开始支持窗口函数，PostgreSQL、Oracle、SQL Server则早就支持。如果你的数据库版本较老，只能退回到NOT IN方案并接受并列分数全部被剔除的行为，或者在应用层做补充处理。
性能优化与常见坑点
当打分表数据量较大时，建议在player_id和score上建立复合索引，例如CREATE INDEX idx_player_score ON scores(player_id, score)。这样无论是子查询里的MAX、MIN，还是窗口函数里的排序，都可以走索引避免额外的排序开销。
还有一个容易忽略的场景：如果需求是去掉最高的N个分和最低的N个分（比如去掉两个最高两个最低），只需把窗口函数方案中的过滤条件改成rn_high > N AND rn_low > N即可，扩展起来非常方便。而用NOT IN实现同样的需求就得在子查询里做ORDER BY加LIMIT，写法复杂得多。
最后提醒一点，剔除极值后再求平均虽然能抵抗异常值干扰，但也可能把真实的极端表现抹掉。比如某选手确实发挥特别出色拿到了全场唯一的满分，剔除它反而低估了实力。所以是否采用这种统计方式，要结合具体业务场景来判断，必要时可以同时输出原始平均分和剔除极值后的平均分，供使用者对比参考。