ROW_NUMBER()在MySQL 8.0中必须配合含ORDER BY的OVER()子句使用，不可独立调用，也不能出现在WHERE或GROUP BY中；漏写ORDER BY会报ERROR 3593，仅写PARTITION BY而无ORDER BY同样非法。
ROW_NUMBER() 在 MySQL 8.0 中必须搭配窗口定义使用
MySQL 8.0 确实支持 ROW_NUMBER()，但它不是独立函数，必须配合 OVER() 子句，且不能出现在 WHERE 或 GROUP BY 中——常见错误是写成 WHERE ROW_NUMBER() OVER (...) ，这会直接报错 <code>Window function is not allowed in WHERE clause。
正确做法是先用子查询或 CTE 把行号算出来，再在外层过滤。例如查每个部门薪资前 3 的员工：
SELECT dept, name, salary
FROM (
SELECT dept, name, salary,
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) AS rn
FROM employees
) t
WHERE rn <= 3;
PARTITION BY 和 ORDER BY 的顺序影响结果稳定性
PARTITION BY dept 定义分组边界，ORDER BY salary DESC 决定组内排序逻辑。如果排序字段存在重复值（比如多个员工同为 15000），ROW_NUMBER() 仍会强制分配唯一序号（1,2,3…），但顺序不确定——MySQL 不保证相同排序键下的物理行顺序。
为避免每次查询结果不一致，建议补一个确定性排序字段，比如主键或时间戳：
- 用
ORDER BY salary DESC, id ASC替代仅按salary - 若业务允许并列，改用
RANK()或DENSE_RANK()更合适
性能敏感场景要警惕全表扫描和临时表
ROW_NUMBER() 是窗口函数，MySQL 需要先完成整个分区的排序才能编号，无法利用索引跳过数据。当 employees 表很大且 dept 值分布不均时（比如 90% 行属于 “tech” 部门），该部门内部排序开销会显著拉高延迟。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
优化方向有限，但可尝试：
- 确保
(dept, salary)有联合索引，至少加速排序阶段的 I/O - 避免在大表上对无过滤条件的
PARTITION BY *使用（如按用户 ID 分组但没加 WHERE） - 若只取 Top 1，考虑用
GROUP_CONCAT() + SUBSTRING_INDEX()替代，有时更快（但不可靠，仅限简单场景）
CTE 写法更清晰，但注意 MySQL 8.0 对递归 CTE 的限制
用 CTE 可提升可读性，尤其多层窗口计算时：
WITH ranked AS (
SELECT dept, name, salary,
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC, id ASC) AS rn
FROM employees
)
SELECT dept, name, salary FROM ranked WHERE rn <= 3;
注意：MySQL 的 CTE 默认是非递归的，无需额外声明；但如果你误加了 RECURSIVE 关键字又没写递归锚点，会报错 Recursive common table expression requires exactly one anchor and one recursive term。单纯做分组 Top N，完全不需要递归。
真正容易被忽略的是：CTE 在 MySQL 中是物化的（即执行一次、结果暂存），如果外层多次引用同一 CTE，不会重复计算——这点和某些 PostgreSQL 版本不同，但也不代表能随意嵌套多层窗口函数，每层仍需完整排序。
