直接用 ROW_NUMBER() 在连接后打标再过滤最稳妥；因 GROUP BY 会丢失明细且 LIMIT 全局生效，无法实现每组 Top N；正确做法是 JOIN 后用 ROW_NUMBER() 按 order_id 分区、sales 降序编号，再筛选 rn ≤ 2。
直接用 ROW_NUMBER() 在连接后打标再过滤，是最稳的路；别在 JOIN 条件里硬塞 LIMIT，也别指望 GROUP BY + ORDER BY + LIMIT 能跑通一对多 Top N。
为什么不能先 JOIN 再 GROUP BY + LIMIT
一对多关联（比如一个订单对应多条商品）下，GROUP BY order_id 会把商品行聚合成一行，原始明细就丢了——你根本拿不到“每个订单里销量最高的前 2 个商品”这种结果。而 LIMIT 是作用于最终结果集的全局限制，不是每组独立生效。
常见错误现象：SELECT o.order_id, i.item_name, i.sales FROM orders o JOIN items i ON o.order_id = i.order_id GROUP BY o.order_id ORDER BY i.sales DESC LIMIT 2 —— 这只会返回总共 2 行，且 i.item_name 和 i.sales 值不可控（依赖 SQL 模式和引擎行为）。
正确写法：JOIN 后立刻用 ROW_NUMBER() 分区标号
核心逻辑是：先完成一对多连接，得到宽表（含所有明细），再按业务单元（如 order_id）分区、按指标（如 sales DESC）排序，打唯一序号，最后外层筛 rn 。
- 必须确保
PARTITION BY字段来自主表（如orders.order_id），而不是从子表随意选——否则分区错位，Top N 失效 -
ORDER BY必须明确降序（DESC），升序会把最差的排前面 - 若存在
NULL指标值（如sales IS NULL），不同数据库处理方式不一（MySQL 默认排最前，PostgreSQL 可能排最后），建议提前加WHERE i.sales IS NOT NULL
示例（每个订单取销量前 2 的商品）：
SELECT order_id, item_name, sales
FROM (
SELECT o.order_id, i.item_name, i.sales,
ROW_NUMBER() OVER (PARTITION BY o.order_id ORDER BY i.sales DESC) AS rn
FROM orders o
JOIN items i ON o.order_id = i.order_id
WHERE i.sales IS NOT NULL
) t
WHERE rn <= 2;容易踩的坑：JOIN 顺序与 NULL 值干扰
如果用 LEFT JOIN（比如要保留无商品的订单），ROW_NUMBER() 仍会对空行生成序号（rn = 1），但 item_name 和 sales 是 NULL，这类记录会被 WHERE rn 错误保留。这时得加额外过滤：
- 要么在窗口子查询里用
INNER JOIN保证有明细 - 要么外层补
AND item_name IS NOT NULL - 或者改用
CASE WHEN控制排序权重，让NULL排最后：ORDER BY i.sales DESC NULLS LAST（PostgreSQL 支持，MySQL 不支持该语法）
另一个隐形陷阱：当连接后数据量极大（比如单个订单关联上万商品），ROW_NUMBER() 会强制扫描并排序整个分区——此时索引 (order_id, sales DESC) 能显著加速，没它的话，性能可能断崖下跌。
MySQL 8.0+ 特别注意子查询嵌套层级
MySQL 对派生表（子查询）的优化较弱，尤其当外层还带 ORDER BY 或复杂 WHERE 时，容易触发 “This version of MySQL doesn’t yet support ‘LIMIT & IN/ALL/ANY/SOME subquery’” 类报错。
实操建议：
- 把窗口计算放在 CTE 里（MySQL 8.0+ 支持），结构更清晰：
WITH ranked AS (SELECT ..., ROW_NUMBER() OVER (...) AS rn FROM ...) - 避免三层以上嵌套子查询，宁可拆成两个临时表或物化中间结果
- 别在窗口函数的
OVER子句里写复杂表达式（如COALESCE(sales, 0) * weight），先算好字段再排序
真正难的不是写出语法，而是确认 PARTITION BY 的粒度是否和业务“推荐单元”完全一致——漏掉一个字段（比如少写 store_id），整组排名就垮了；多写一个（比如混进 date），又会导致本该合并的组被强行切碎。这点没法靠工具检查，只能靠对业务的理解压到代码里。
