不能直接用 max() 配合 row_number()，因二者语义冲突：max() 压缩行，row_number() 依赖原始行编号；正确做法是先用 row_number() 窗口函数分组排序编号，再外层 where rn ≤ n 筛选 topn。
为什么不能直接用 MAX() 配合 ROW_NUMBER()？
因为 MAX() 是聚合函数，ROW_NUMBER() 是窗口函数，二者语义冲突：前者压缩行，后者依赖原始行生成序号。强行混用（比如在同一个 SELECT 里对同一列既 MAX() 又 ROW_NUMBER() OVER (...)）会导致逻辑矛盾——你没法对“每组最大值”再排一次“组内序号”。真正可行的是用 ROW_NUMBER() 先排序标序，再用外层过滤取 TopN。
标准写法：用 ROW_NUMBER() 窗口函数 + 外层 WHERE 过滤
核心思路是把排序和筛选拆开：先在子查询或 CTE 中为每组数据按目标字段降序编号，再在外层挑出序号 ≤ N 的记录。这是最通用、可读性最强、兼容主流数据库（PostgreSQL / SQL Server / Oracle / MySQL 8.0+）的做法。
常见错误现象：Window function is not allowed in WHERE clause（MySQL/PostgreSQL 报错），说明你试图在 WHERE 里直接写 ROW_NUMBER() OVER (...) —— 窗口函数不能出现在 WHERE 或 GROUP BY 中。
- 必须用子查询或 CTE 包裹窗口函数结果
-
ORDER BY子句在ROW_NUMBER() OVER (ORDER BY ...)里决定 TopN 的“谁排前面”，别漏掉DESC - 分组字段要写全在
PARTITION BY里，比如按部门查 Top3 薪资，就得PARTITION BY dept_id - 如果存在并列（相同 salary），
ROW_NUMBER()会强制分配不同序号；需要并列保留用RANK()或DENSE_RANK()
SELECT dept_id, emp_name, salary
FROM (
SELECT dept_id, emp_name, salary,
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC) AS rn
FROM employees
) t
WHERE rn <h3>性能关键：PARTITION BY 和 ORDER BY 字段必须有索引</h3><p>没有索引时，<code>ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY salary DESC)</code> 会触发全表扫描 + 内存排序，大数据量下极慢。尤其当 <code>PARTITION BY</code> 和 <code>ORDER BY</code> 组合高频使用（如查各品类销量 Top10），索引设计直接影响能否跑通。</p>
- 最优索引：复合索引
(dept_id, salary DESC)—— 覆盖分区键和排序键 - 如果查询还带其他
WHERE条件（如status = 'active'），需把该字段前置，变成(status, dept_id, salary DESC) - MySQL 5.7 或更早不支持函数索引，但
PARTITION BY字段本身必须是确定值，不能是表达式（如PARTITION BY YEAR(hire_date)会导致无法走索引）
替代方案：用 LATERAL / APPLY（SQL Server / PostgreSQL）避免嵌套
当 TopN 逻辑复杂（比如要关联最新订单时间、还要过滤状态），深层子查询可读性差。此时可用 CROSS APPLY（SQL Server）或 LATERAL（PostgreSQL）把 TopN 当作“每组的子查询”来写，语义更直白，优化器也更容易下推条件。
容易踩的坑：LATERAL 在 PostgreSQL 中要求右侧子查询必须引用左侧表字段；SQL Server 的 APPLY 不支持在 ON 子句中直接写 TOP，得用子查询包裹。
-- PostgreSQL 示例：查每个部门薪资最高的员工（仅1人） SELECT d.dept_name, e.emp_name, e.salary FROM departments d CROSS JOIN LATERAL ( SELECT emp_name, salary FROM employees e2 WHERE e2.dept_id = d.dept_id ORDER BY salary DESC LIMIT 1 ) e;
复杂点在于：LATERAL/APPLY 本质是循环驱动，若左侧数据量大（比如 10 万部门），即使每个子查询都命中索引，I/O 次数也会线性增长。这时候不如回到带索引的窗口函数方案。
