ROW_NUMBER() 是SQL中实现“每组取前N条”的最通用解法，需用子查询或CTE包裹后在外部WHERE中过滤rn≤N。
用 ROW_NUMBER() 配合 WHERE 筛选最直接
SQL 标准里没有“每组取前 N 条”的原生命令，但 ROW_NUMBER() 是最通用、可读性最强的解法。它给每组内记录按指定顺序编号，再用外层 WHERE 过滤出编号 ≤ N 的行。
注意：必须用子查询或 CTE 包裹，因为窗口函数不能直接出现在 WHERE 子句中。
SELECT user_id, order_date, amount
FROM (
SELECT user_id, order_date, amount,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY amount DESC) AS rn
FROM orders
) t
WHERE rn <= 3;-
PARTITION BY user_id定义分组维度，换成category或region也一样 -
ORDER BY amount DESC决定“前 N 条”的依据；若要取最新订单，改用ORDER BY order_date DESC - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 3.25+ 也支持
- 别用
RANK()或DENSE_RANK()——它们会跳号，导致实际返回条数少于 N
MySQL 5.7 或更老版本只能靠自连接或变量模拟
这些旧版本不支持窗口函数，ROW_NUMBER() 不可用。强行用用户变量（如 @rn := @rn + 1）虽然能跑，但官方已明确警告：变量赋值顺序不保证，结果可能错乱，尤其在有 ORDER BY 或并行执行时。
稳妥做法是降级为自连接计数，但性能差、写法绕：
SELECT o1.user_id, o1.order_date, o1.amount
FROM orders o1
WHERE (
SELECT COUNT(*)
FROM orders o2
WHERE o2.user_id = o1.user_id
AND o2.amount > o1.amount
) < 3;- 该写法本质是“找比当前记录 amount 更大的同组记录少于 3 个的行”，等价于 Top 3
- 必须确保
WHERE中的关联条件完整，漏掉user_id就变成全表比较 - 索引很关键：
(user_id, amount)复合索引能大幅加速子查询 - 数据量稍大（比如单组超 1000 行）就明显变慢，别在线上环境硬扛
PostgreSQL 可用 LATERAL JOIN 简化逻辑
如果只是想查每组 top N，且后续还要关联其他表或做聚合，LATERAL 比嵌套子查询更清晰，语义上也更贴近“对每个分组执行一次子查询”。
SELECT u.user_id, top_orders.order_date, top_orders.amount FROM users u LATERAL ( SELECT order_date, amount FROM orders o WHERE o.user_id = u.user_id ORDER BY amount DESC LIMIT 3 ) top_orders;
-
LATERAL允许子查询引用左侧行（这里是u.user_id），这是关键 -
LIMIT在子查询里直接生效，不用编号再过滤，代码更短 - 仅 PostgreSQL 支持；SQL Server 有类似
APPLY，但语法不同 - 若
users表有 10 万用户，这个查询会执行 10 万次子查询——务必确认orders(user_id, amount)有索引
GROUP BY 后加 LIMIT 是常见误解
很多人直觉写 SELECT ... GROUP BY user_id LIMIT 3，但这只会返回前 3 个分组，不是每个分组的前 3 条。
另一个典型错误是把 ROW_NUMBER() 放在 GROUP BY 查询里，比如：
SELECT user_id, MAX(amount), ROW_NUMBER() OVER (...) -- ❌ 错误！GROUP BY 和窗口函数混用会报错或语义混乱
- 窗口函数和聚合函数（
MAX、COUNT）不能共存于同一层级的SELECT，除非先用子查询分开 - 想同时看每组 top 3 的明细 + 该组总金额？得两层嵌套：内层取 top N，外层再
GROUP BY聚合 - 某些 BI 工具（如早期 Tableau）生成的 SQL 会偷偷加
GROUP BY，结果却想取明细——这时候要检查生成逻辑，而不是硬调 SQL
真正麻烦的是分页场景：比如“每组取第 2 到第 5 条”。这时 ROW_NUMBER() 依然可用，但 LATERAL 或自连接就得重写条件，容易漏边界。另外，如果 N 是动态参数（比如来自应用层变量），部分数据库对预编译语句的支持有限制，得确认驱动是否允许 LIMIT ? 这种写法。
