ROW_NUMBER()必须配合OVER()使用，否则报错；OVER()中至少需ORDER BY，分组取前N条需PARTITION BY；MySQL 5.7及以下不支持；注意NULL处理、索引优化与执行时机。
ROW_NUMBER() 必须配合 OVER() 使用，否则直接报错
不写 OVER() 是新手最常踩的坑——ROW_NUMBER() 不是普通函数，它没有默认排序逻辑，也不接受任意参数。漏掉括号或里面没写 ORDER BY，MySQL 8.0+、PostgreSQL、SQL Server 都会报类似 "Window function requires an OVER clause" 的错误。
实操建议：
-
OVER()里至少得有ORDER BY，否则结果不可预测（即使语法通过） - 如果还要分组取前 N，必须加
PARTITION BY，顺序是PARTITION BY ... ORDER BY ... - 别在
WHERE里过滤行号，因为窗口函数在WHERE之后执行；得用子查询或 CTE
MySQL 8.0+ 和 PostgreSQL 写法一致，但旧版 MySQL 不支持
如果你用的是 MySQL 5.7 或更早版本，ROW_NUMBER() 直接不可用，强行写会报 "FUNCTION xxx.ROW_NUMBER does not exist"。这不是语法错，是版本硬限制。
实操建议：
- 先查版本：
SELECT VERSION();，低于 8.0 就得换方案（比如变量模拟或自关联） - PostgreSQL 用户注意：
ROW_NUMBER()在子查询中可用，但不能出现在HAVING或GROUP BY中 - SQL Server 用户可放心用，但记得避免在视图里用未明确排序的
ORDER BY，否则可能触发警告
取“每组前 N 条”时，PARTITION BY 字段必须和业务分组维度严格一致
比如想按 category 取销量 Top 3，但误写成 PARTITION BY category_id，而表里 category 和 category_id 并不一一对应，结果就会漏组或多组。
实操建议：
- 先用
SELECT DISTINCT category FROM table确认分组字段实际值，再决定是否需要COALESCE()或CASE WHEN预处理 - 如果分组依据是多字段（如
(region, year)），务必用括号包裹，写成PARTITION BY region, year即可，不用额外括号 - 注意 NULL 值：不同数据库对
PARTITION BY中 NULL 的处理一致（通常视为同一组），但若业务上要排除 NULL，得提前在WHERE过滤
性能敏感场景下，ORDER BY 字段必须有索引
窗口函数本身不走索引，但 OVER(ORDER BY x) 的排序过程会显著拖慢查询——尤其当分区大、排序字段无索引时，可能从毫秒级升到秒级。
实操建议：
- 给
PARTITION BY + ORDER BY组合建联合索引，例如INDEX idx_cat_sales (category, sales DESC) - 避免在
ORDER BY里用函数或表达式（如ORDER BY UPPER(name)），会导致索引失效 - 如果只是取前 N 条且 N 很小（比如 3），考虑用
LIMIT+UNION ALL分组查（适合分组数少、N 极小的场景），比窗口函数更快
真正容易被忽略的是：窗口函数的执行时机决定了它看不到 WHERE 后的结果集，也影响不到 GROUP BY 分组逻辑。写完记得用小数据集验证行号是否按预期重置——有时候你以为分了组，其实 PARTITION BY 字段全为 NULL 或存在隐藏空格，导致所有行挤在同一组里。
