group by 不能直接生成排名，必须先聚合再用窗口函数排序；rank()适合排位赛（同分同名次且跳位），而row_number()和dense_rank()适用场景不同；mysql 5.7需用变量模拟，但推荐升级至8.0+。
GROUP BY 本身不能直接生成排名，得靠窗口函数
很多人写 GROUP BY 后想顺手加个 RANK() 或 ROW_NUMBER()，结果报错：column "xxx" must appear in the GROUP BY clause or be used in an aggregate function。这是因为标准 SQL 中，GROUP BY 后只允许出现分组列或聚合表达式，而排名函数属于“窗口计算”，和聚合逻辑冲突——它需要逐行计算，不是按组归约。
真正要实现排位赛统计（比如按队伍总分排序、同分同名次、带并列跳位），必须把排名逻辑放在窗口函数里，且不能和 GROUP BY 混在同一层级。常见做法是先聚合，再套一层查询用窗口函数排位。
- 先用
GROUP BY team_id算出每队总分：SUM(score) - 外层查这个结果集，用
RANK() OVER (ORDER BY total_score DESC)排名 - 别在同一个
SELECT里既写GROUP BY又写RANK()，MySQL 8.0+ / PostgreSQL / SQL Server 都不认
排位类型选错会导致名次逻辑出错
排位赛常要求“同分同名次，后续名次跳过”，比如分数 100, 95, 95, 90 → 名次应为 1, 2, 2, 4。但有人误用 ROW_NUMBER() 得到 1, 2, 3, 4，这就不是排位赛规则了。
-
RANK()：同值同名次，跳位（推荐用于排位赛） -
DENSE_RANK()：同值同名次，不跳位（1,2,2,3）→ 适合梯队划分，不适合正式排名 -
ROW_NUMBER()：强制唯一序号（1,2,3,4）→ 仅适用于抽签或流水号 - 注意排序方向：
ORDER BY total_score DESC才是高分在前；漏写DESC会把最低分排第一
MySQL 5.7 不支持窗口函数，得用变量模拟
如果还在用 MySQL 5.7 或更老版本，RANK() 直接报错 FUNCTION xxx.RANK does not exist。此时只能靠用户变量硬撸，但要注意执行顺序不可靠、并发下易错乱，仅限低并发报表场景。
SELECT team_id, total_score, @rank := IF(@prev = total_score, @rank, @rank + @step) AS rank_num, @step := IF(@prev = total_score, @step + 1, 1), @prev := total_score FROM ( SELECT team_id, SUM(score) AS total_score FROM matches GROUP BY team_id ORDER BY total_score DESC ) t, (SELECT @rank := 0, @step := 1, @prev := NULL) r;
- 变量赋值顺序依赖
ORDER BY生效，必须显式排序且不能有 LIMIT 在子查询里打乱顺序 - 不能在视图或存储过程中安全复用这套逻辑
- 升级到 MySQL 8.0 是一劳永逸的解法，别在线上硬扛变量方案
GROUP BY + 窗口函数嵌套时容易漏掉分组字段
写两层查询时，外层 SELECT 的字段必须全部来自内层结果，否则会报 unknown column。典型错误是内层 GROUP BY team_id 但忘了选 team_name，外层却直接引用它。
- 内层聚合查询必须包含所有业务需要的非聚合字段，例如：
SELECT team_id, team_name, SUM(score) AS total_score GROUP BY team_id, team_name - 如果
team_name和team_id是 1:1 关系，MySQL 5.7+ 有ONLY_FULL_GROUP_BY关闭时可能放行，但其他数据库会直接拒掉 - 别指望数据库自动“猜”你想要哪个
team_name，没出现在GROUP BY里的非聚合列就是隐患
排位赛统计真正的复杂点不在语法，而在数据一致性：分数来源是否实时？并列规则是否被裁判组确认？这些比 RANK() 少写一个 DESC 更容易让结果失效。
