应根据是否允许并列选择：需并列名次用 RANK()（如1,1,3），需严格连续序号用 ROW_NUMBER()（如1,2,3）；误用 RANK() 可能导致筛选结果超预期。
用 RANK() 还是 ROW_NUMBER()？关键看重复值怎么算
如果同一分类下有多个记录的排序字段（比如销售额）相同，RANK() 会给出相同名次，跳过后续名次（如 1,1,3）；ROW_NUMBER() 则强制连续编号（1,2,3）。业务上要求“并列也算前三”，就选 RANK()；要求“严格取三条记录”，必须用 ROW_NUMBER()。
常见错误是直接套用 RANK() 却没意识到并列会导致返回超过 3 行——比如某分类里前四条全是并列第 1 名，RANK() 全标为 1，WHERE 条件 rn 就会全中。
- 优先按业务语义选函数：
ROW_NUMBER()更可控，适合“每个分类只取最多三条” - 排序字段含 NULL 时，
ORDER BY score DESC默认把 NULL 排最前，需加NULLS LAST（MySQL 8.0.22+ 支持）或用IFNULL(score, -999999)干预 - 分区键（
PARTITION BY category）字段若有隐式类型转换（如字符串混数字），可能造成意外分组，建议显式CAST(category AS CHAR)
子查询嵌套必须带别名，否则报错 ERROR 1248 (42000): Every derived table must have its own alias
MySQL 强制要求 FROM 子句中的子查询必须有别名，窗口函数结果也不例外。漏写别名是最常见的语法错误，尤其从其他数据库（如 PostgreSQL）迁移过来时容易忽略。
正确写法是把整个窗口计算逻辑包进一个子查询，并在末尾加 AS t 类似结构：
SELECT category, name, score
FROM (
SELECT category, name, score,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY score DESC) AS rn
FROM products
) AS t
WHERE rn <= 3;
注意：别名 t 后不能跟括号，也不能省略 AS（虽然 MySQL 允许省略，但显式写出更安全、可读性更强）。
ORDER BY 在窗口函数内外同时存在，执行顺序怎么理解？
窗口函数里的 ORDER BY（如 OVER (PARTITION BY x ORDER BY y DESC)）只影响该窗口内行的排序和编号逻辑；外层 ORDER BY 控制最终结果集的显示顺序，两者互不干扰。
典型需求是“每个分类内按 score 降序排，但整体结果按 category 升序、再按名次升序展示”。这时必须在外层显式加 ORDER BY category, rn，否则输出顺序不确定。
- 窗口函数的
ORDER BY是计算前提，不保证最终输出顺序 - 如果外层没写
ORDER BY，MySQL 返回顺序取决于执行计划（如索引扫描方向），不可依赖 - 复合排序时，外层
ORDER BY category, rn比ORDER BY category, score DESC更准确——因为score可能重复，而rn是唯一确定的
性能差？检查是否命中分区字段 + 排序字段的联合索引
窗口函数本身不走索引，但 PARTITION BY 和 ORDER BY 的字段组合如果有对应联合索引，MySQL 能大幅减少排序开销。例如对 PARTITION BY category ORDER BY score DESC，最佳索引是 INDEX(category, score)（注意顺序：先分区键，再排序键）。
用 EXPLAIN 看执行计划时，重点确认 type 是否为 ref 或 range，且 Extra 字段不含 Using filesort。如果出现 Using temporary; Using filesort，基本说明索引没生效或缺失。
- 单列索引
INDEX(category)或INDEX(score)都无法优化该窗口场景 - 如果
category值分布极不均匀（比如 90% 数据集中在 3 个分类），即使有索引，大分类内部排序仍可能慢，此时考虑加LIMIT分批处理 -
ROW_NUMBER()比RANK()略快，因无需做相等值检测；实际差异通常不大，优先按语义选
