MySQL 8.0中ROW_NUMBER()等窗口函数必须配合OVER()使用，缺ORDER BY或PARTITION BY会导致语法错误或逻辑错误；三者区别在于并列处理方式：ROW_NUMBER()严格序号，RANK()并列跳号，DENSE_RANK()并列不跳号。
MySQL 8.0 分组排序必须用 OVER() 配合 PARTITION BY，漏掉任一都得不到“每组内独立编号”的效果。
为什么 ROW_NUMBER() 单独写就报错
不是版本问题，也不是没启用功能——ROW_NUMBER() 根本不是普通函数，它没有独立语义。MySQL 解析器看到 ROW_NUMBER() 后找不到 OVER，直接判定为语法错误：ERROR 1064 (42000): You have an error in your SQL syntax。
实操建议：
-
OVER必须存在，且至少含ORDER BY（哪怕你只想要乱序编号，也得显式写ORDER BY id，否则结果不可复现） - 别在子查询或
WHERE里调用窗口函数——它只能出现在SELECT列表或HAVING（配合聚合时） - 如果只是想给全表加序号，写成
ROW_NUMBER() OVER (ORDER BY id)即可，不用PARTITION BY
PARTITION BY 漏写会导致全局排序而非分组排序
常见现象：你本想按部门取 Top 3 员工，结果查出来只有 3 条记录，或者所有人的 rn 值都是 1～3 的循环——这基本是 PARTITION BY dept_id 被漏掉了，ROW_NUMBER() 就默认把整张表当一个窗口处理。
实操建议：
-
PARTITION BY和ORDER BY的顺序不能颠倒：必须是PARTITION BY ... ORDER BY ...，反过来会报错 - 多个分组字段用逗号分隔，如
PARTITION BY region, product_type -
PARTITION BY字段值为NULL会被归为同一组，注意清洗或用COALESCE(dept_id, 'unknown')显式控制
分组内排名该选 ROW_NUMBER()、RANK() 还是 DENSE_RANK()
三者行为差异不在语法，而在业务语义：并列时要不要跳号。比如两个员工同为 15k 薪资，在「每个部门薪资 Top 3」场景下：
-
ROW_NUMBER()给 1、2、3 —— 严格按物理顺序排，无并列概念 -
RANK()给 1、1、3 —— 并列后跳过被占位次，适合“名次即席位”逻辑 -
DENSE_RANK()给 1、1、2 —— 并列不跳号，适合“名次即等级”逻辑（如职级 A/B/C）
注意：RANK() 和 DENSE_RANK() 同样要求 OVER，且不能用于 WHERE；若要过滤 Top 3，必须用 CTE 或子查询套一层：SELECT * FROM (SELECT ..., ROW_NUMBER() OVER (...) AS rn FROM t) t1 WHERE rn 。
OVER() 里的 ORDER BY 不等于主查询的 ORDER BY
这是最容易混淆的点：窗口函数里的 ORDER BY 只决定编号/排名/累计等计算所依赖的行序，不影响最终返回结果的显示顺序。你可能看到 ROW_NUMBER() 编号是乱的，但数据本身按部门排好了——那是因为主查询没写 ORDER BY dept_id, salary DESC。
实操建议：
- 计算逻辑靠
OVER(ORDER BY ...)，展示顺序靠外层ORDER BY - 如果两者排序字段一致，可以省略外层
ORDER BY，但别假设“有窗口排序就等于结果有序” - 日期类排序尤其要注意重复值：用
ORDER BY create_time, id补充唯一性，避免相同时间戳导致窗口内顺序不稳定
真正难的不是写对语法，而是想清楚“分组依据是否覆盖所有业务维度”“并列规则是否匹配考核口径”“窗口排序是否引入了隐式依赖”。这些没法靠 EXPLAIN 看出来，得对照业务数据手工验几条。
