大多数情况下，不使用窗口函数，通过GROUP BY与ORDER BY和LIMIT的组合，同样能实现分组聚合后取前10的操作。不过要记住，SELECT中的所有非聚合字段都必须出现在GROUP BY子句中（尤其是在MySQL 5.7+的严格模式下）。另外，LIMIT只限制物理行数，不支持逻辑排名。如果需要并列排名，就得使用DENSE_RANK()函数，并将其嵌套在子查询中。

用 GROUP BY + ORDER BY + LIMIT 最直接

多数场景下，你不需要窗口函数。只要按分组聚合后排序取前10，GROUP BY 配合 ORDER BY ... DESC 和 LIMIT 10 就够了。

常见错误是漏写 GROUP BY 或把非聚合字段塞进 SELECT，导致语法报错或结果不可靠。

• 必须确保 SELECT 中所有非聚合字段都出现在 GROUP BY 子句里（MySQL 5.7+ 严格模式下尤其明显）
• 聚合函数如 SUM(sales_amount) 才能代表“该分组的销售额”
• LIMIT 10 要放在最后，且不支持带偏移量的“第11–20名”这种写法（除非用 OFFSET，但注意性能）

SELECT region, SUM(sales_amount) AS total_sales
FROM orders
GROUP BY region
ORDER BY total_sales DESC
LIMIT 10;

需要并列排名时必须用 DENSE_RANK()

如果两个分组销售额都是 95 万，并列第3，下一个应该是第4（不是第5），就得靠窗口函数。此时 LIMIT 失效，因为它是物理行数限制，不是逻辑排名限制。

常见的陷阱在于对 RANK() 或 ROW_NUMBER() 的误用：ROW_NUMBER() 会给重复值强制分配不同的序号，RANK() 则会出现跳名次的情况（例如1,2,2,4），而只有 DENSE_RANK() 才符合“并列不跳”的业务逻辑。

• 必须用子查询或 CTE 包裹，否则不能在 WHERE 中直接过滤窗口函数结果
• PostgreSQL / SQL Server / MySQL 8.0+ 支持；老版本 MySQL（5.7 及更早）不支持，得用变量模拟，极易出错
• 性能上，窗口函数比简单 GROUP BY 开销大，数据量大时要注意执行计划

SELECT region, total_sales
FROM (
SELECT region, SUM(sales_amount) AS total_sales,
 DENSE_RANK() OVER (ORDER BY SUM(sales_amount) DESC) AS rk
FROM orders
GROUP BY region
) t
WHERE rk <= 10;

MySQL 5.7 怎么绕过窗口函数缺失问题

没 DENSE_RANK() 也不等于没法做并列排名。核心思路是：用自连接或变量统计“有多少个分组销售额 ≥ 当前分组”，这个数量就是它的密集排名。

但变量方案脆弱——依赖执行顺序，ORDER BY 必须显式写出，且无法在复杂查询（如多表 JOIN 后分组）中稳定工作。

• 推荐优先升级到 MySQL 8.0+，变量模拟只是临时补救
• 若坚持用变量，@rank := @rank + (@prev != total_sales) 这类写法容易因 NULL 或类型隐式转换崩掉
• 自连接方案（对每个分组查大于等于它的分组数）在数据量超 1 万行时基本不可用，N 复杂度

SELECT region, total_sales
FROM (
SELECT region, total_sales,
 @rank := IF(@prev = total_sales, @rank, @rank + 1) AS rk,
 @prev := total_sales
FROM (
SELECT region, SUM(sales_amount) AS total_sales
FROM orders
GROUP BY region
ORDER BY total_sales DESC-- 必须有！否则变量行为未定义
) t, (SELECT @rank := 0, @prev := NULL) r
) ranked
WHERE rk <= 10;

分组字段含 NULL 时排名结果可能不符合预期

GROUP BY 中若分组字段（如 region）有 NULL 值，它会被当作一个独立分组参与聚合和排序。但业务上往往不希望 NULL 占一个“前10”名额。

更隐蔽的问题是：某些数据库（如 PostgreSQL）默认把 NULL 排在最前（NULLS FIRST），而另一些（如 MySQL）默认排最后，ORDER BY ... DESC 下 NULL 可能意外卡进前10。

• 明确加 WHERE region IS NOT NULL 过滤，比依赖排序行为更可靠
• 如果业务真要保留 NULL 分组，需确认是否允许它参与排名，以及期望的排序位置
• 用 COALESCE(region, 'Unknown') 替换 NULL 是常见做法，但注意这会改变分组逻辑

真正麻烦的不是语法，而是“前10”这个需求背后常混着模糊的业务规则：要不要去重？并列怎么算？NULL 算不算一个有效分组？这些不厘清，SQL 写得再漂亮也容易返工。

《夸克》非常好用的免费AI浏览器

下载APP查看