mysql 8.0+ 应使用 row_number() 实现每组前3条：需配合 over (partition by group_col order by sort_col desc)，避免遗漏 partition by 或误在外部 where 中引用别名。
MySQL 8.0+ 用 ROW_NUMBER() 最直接
如果你用的是 MySQL 8.0 或更高版本，ROW_NUMBER() 是最干净的解法。它按分组排序后给每行标序号，再筛出序号 ≤ 3 的记录。
常见错误是忘记 PARTITION BY 或写错排序字段，导致“前3条”变成全局前3，而不是每组各自前3。
- 必须配合
OVER (PARTITION BY group_col ORDER BY sort_col DESC)使用，PARTITION BY定义分组维度，ORDER BY决定组内顺序 - 别在外部查询里对
ROW_NUMBER()别名直接加WHERE rn —— 需包一层子查询或 CTE，否则报错 “Unknown column 'rn'” - 示例：
WITH ranked AS ( SELECT *, ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC) AS rn FROM products ) SELECT * FROM ranked WHERE rn
MySQL 5.7 及更早版本只能靠自连接或变量模拟
老版本不支持窗口函数，@row_number 变量方案看似简洁，但极易出错：变量执行顺序不保证，尤其在有 ORDER BY 或涉及索引跳过时，序号会乱。
更稳的办法是自连接（correlated subquery），虽然性能差，但逻辑清晰、结果确定。
- 自连接写法本质是：对每条记录，统计同组中比它“更好”的记录数（比如销售额更高的数量），若小于3，则入选
- 注意
和 <code> 的边界——要取前3，条件得是 <code>(SELECT COUNT(*) FROM t2 WHERE t2.group_col = t1.group_col AND t2.score > t1.score) - 如果存在并列（如多个相同最高分），
ROW_NUMBER()会强制分先后，而自连接可能返回超过3条；需要严格 Top-N 且允许并列时，改用RANK()（但老版本也不支持）
PostgreSQL / SQL Server 直接用 ROW_NUMBER() 或 FETCH FIRST
PostgreSQL 支持 ROW_NUMBER() 语法和 MySQL 8.0 几乎一致；SQL Server 从 2005 就支持，写法也相同。
PostgreSQL 还可配合 LATERAL + FETCH FIRST 实现更直观的“每组取前N”逻辑，适合 N 较小且分组键明确的场景：
-
LATERAL允许在JOIN中引用左表字段，实现“对每个 category，查其下销量最高的3个 product” - 示例：
SELECT c.category, p.* FROM categories c LEFT JOIN LATERAL ( SELECT * FROM products p2 WHERE p2.category = c.category ORDER BY p2.sales DESC FETCH FIRST 3 ROWS ONLY ) p ON true;
- 这种写法避免了窗口函数的中间结果膨胀，内存友好，但要求 PostgreSQL ≥ 9.3
性能和数据一致性容易被忽略的点
不管用哪种方法，“每组前3”本质上都是非索引友好操作，特别是分组字段基数高（比如上万组）时，ROW_NUMBER() 会先全量排序再过滤，内存和时间开销明显。
- 确保
PARTITION BY和ORDER BY字段上有联合索引，例如(category, sales DESC)，能极大加速 MySQL/PG 的窗口函数执行 - 如果只是展示用、不要求绝对实时，考虑预计算：用定时任务把每组 Top3 结果存到物化视图或汇总表，查时直取
- 业务上真需要“前3”，还是“至少有一个Top3代表”？有时用
GROUP_CONCAT(DISTINCT ... ORDER BY ... LIMIT 3)（MySQL）或STRING_AGG(...) WITHIN GROUP (ORDER BY ...)（PG）聚合后截断，更省资源
