MySQL 8.0 首次支持窗口函数，5.7 完全不支持且报错；其执行阶段在 SELECT，故别名不可用于 WHERE，须用 CTE；强制 ORDER BY 提升确定性，并依赖 PARTITION BY 与 ORDER BY 对齐业务语义。
MySQL 8.0 的窗口函数不是“比 5.7 更好用”，而是 5.7 根本不支持——直接报错 ERROR 1305: FUNCTION xxx does not exist。 所有 ROW_NUMBER()、RANK()、DENSE_RANK() 在 5.7 中都不存在，强行写会语法失败，不是性能差，是根本跑不通。
5.7 里模拟排名只能靠变量，但结果不可靠
很多人在 5.7 用 @rank := @rank + 1 或 @rank := IF(@dept = dept, @rank + 1, 1) 模拟分组排名，但这依赖执行顺序，而 MySQL 不保证变量赋值顺序：
- ORDER BY 和变量计算可能被优化器重排，导致同一 SQL 多次执行返回不同序号
- 并发查询下变量状态共享或覆盖，
@rank可能跳变或归零 - 无法在子查询、JOIN 或 WHERE 中安全复用变量结果，一加过滤就失效
- 没有
PARTITION BY语义，手动模拟分组极易漏条件，比如漏写@dept := dept就变成全表编号
8.0 的窗口函数强制要求 ORDER BY，反而提升了确定性
写 ROW_NUMBER() OVER (PARTITION BY class) 直接报 ERROR 3593，看似麻烦，实则是保护机制：
- 必须显式写
ORDER BY score DESC, id ASC，避免因重复值导致非确定排序 - 联合索引
(class, score DESC, id)能让整个窗口计算走索引，不用临时文件排序 -
ORDER BY 1虽语法通过，但字段位置随 SELECT 列变动而失效，生产环境禁用
取每组 Top N 必须用 CTE 或派生表，不能 WHERE 引用别名
这是最容易翻车的点：窗口函数别名（如 rn）在 WHERE 阶段不可见，因为执行顺序是 FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，而窗口计算在 SELECT 阶段才发生。
- 错写：
SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t WHERE rn = 1→ 报错Unknown column 'rn' - 正解：用 CTE 封装，再外层过滤：
WITH ranked AS (<br> SELECT *, ROW_NUMBER() OVER (PARTITION BY dept ORDER BY salary DESC) AS rn<br> FROM emp_salary<br>)<br>SELECT * FROM ranked WHERE rn <= 3;
- 漏写
PARTITION BY dept会导致rn = 1返回全校/全公司最高薪者，而非每个部门各一人
真正难的不是写法，而是理解窗口函数的执行阶段和分区边界——它不靠“技巧”生效，靠的是明确的 PARTITION BY 和稳定的 ORDER BY 组合。一旦这两项没对齐业务语义，结果就不是慢一点，而是逻辑错位。
