RANK() 并列跳号（如1,1,3），适用于真实名次场景；ROW_NUMBER() 强制唯一编号（如1,2,3），适用于分页或唯一序号需求。
用 RANK() 还是 ROW_NUMBER()？销售排名里并列怎么算
销售数据常要按销售额排“第几名”，但并列情况很常见——比如两个销售员都卖了 100 万，该算第 1 名还是第 2 名？RANK() 和 ROW_NUMBER() 行为完全不同：RANK() 并列时跳号（1,1,3），ROW_NUMBER() 强制不重复（1,2,3）。别硬背，看业务：要“真实名次感”（比如发奖只取前 3 名，第 3 名有两人）就用 RANK()；要“唯一序号”（比如分页取第 10–20 条）必须用 ROW_NUMBER()。
容易踩的坑：
-
RANK()在ORDER BY相同值时不会随机打乱，但也不保证物理顺序稳定——如果没加ORDER BY第二字段（如salesperson_id），同一语句多次执行可能返回不同排序 - MySQL 8.0+ 才原生支持这些窗口函数；旧版得用变量模拟，极易出错，不建议硬扛
- 别在
WHERE里直接写RANK() > 10——窗口函数不能出现在WHERE，得套一层子查询或 CTE
按区域 + 时间分组做销售 Top 3，PARTITION BY 怎么写才不出错
想查“每个大区每月销售额 Top 3 的销售员”，关键在 PARTITION BY 的粒度。它必须和你要“分别排名”的维度完全一致：这里是 PARTITION BY region, YEAR(order_date), MONTH(order_date)。漏掉 YEAR 或混用 DATE_FORMAT(order_date, '%Y-%m') 看似等价，但后者可能因时区/隐式转换导致分区错乱。
实操建议：
- 分区字段类型要一致：如果
region是VARCHAR，别用CAST(region AS INT)去分区，会把所有非数字区域归成 NULL 组 - 分区键里避免表达式，尤其别写
PARTITION BY UPPER(region)——多数数据库不支持表达式分区，会报错Window function 'RANK' with expression in PARTITION BY is not allowed - 如果分区后数据量极大（比如每区每月上万条），
ORDER BY sales_amount DESC必须有对应索引，否则排序变全表扫描
NTILE(4) 分四档做销售绩效分层，为什么结果档位数总不对
NTILE(4) 不是“按值切分”，而是把结果集**行数均分**成 4 组。比如共 10 条记录，它强行分出大小为 3,3,2,2 的四组——所以你看到“第 4 档只有 2 人”，不是数据少，是算法如此。它适合“强制等频分箱”，不适合“按销售额 0–50 万、50–100 万…” 这种等宽分箱。
常见错误现象：
- 对空值（
NULL销售额）也分配档位，导致“未开单”被塞进某档——先用WHERE sales_amount IS NOT NULL过滤 - 误以为
NTILE(4)能替代CASE WHEN分段逻辑，结果高销售额被分到低档（因为总行数少，高档位只占 1 行） - 在
GROUP BY后直接套NTILE()，但窗口函数作用于分组前的原始行，不是聚合后的结果——得先聚合再开窗，或改用子查询
MySQL 8.0 排名慢？ORDER BY 没走索引的典型表现
执行 SELECT RANK() OVER (ORDER BY sales_amount DESC) ... 却要几秒，大概率是 sales_amount 列没索引，或索引失效。窗口函数的 ORDER BY 需要排序，没索引就触发 filesort，数据一过十万行就明显卡顿。
检查与优化：
- 用
EXPLAIN看Extra字段是否含Using filesort—— 有就是排序没走索引 - 建联合索引优先考虑
PARTITION BY字段前置，例如INDEX(region, sales_amount)，比单列INDEX(sales_amount)更高效 - 如果只查 Top N，别用
RANK()全量计算再LIMIT，改用ORDER BY sales_amount DESC LIMIT 10+ 应用层补名次，省掉开窗开销
真正麻烦的是既要分组排名、又要跨多表 JOIN、还要实时响应——这时候别硬拼 SQL，该物化中间结果就物化，该加缓存就加缓存。窗口函数不是银弹，它清晰，但不总是快的。
