需要“并列不跳号”用 rank()，需要“严格递增序号”用 row_number()；BI 中多数场景（如销售 TOP10）应选 row_number()，因其保证唯一递增序号，避免前端交互异常。
rank() 和 row_number() 在 BI 报表里到底该选哪个
直接说结论：需要“并列不跳号”用 rank()，需要“严格递增序号”用 row_number()。BI 看板里多数排名需求其实是后者——比如“销售 TOP10”，哪怕两人同分，也得排成第 1、第 2，不能都叫第 1 然后跳到第 3。
常见错误是看到“排名”就默认用 rank()，结果导出到 Tableau 或 Power BI 后发现排序错乱、筛选异常，其实是窗口函数输出的重复值干扰了前端交互逻辑。
-
rank()：相同值获得相同名次，后续名次跳过（如 1,1,3） -
row_number()：纯按排序顺序硬编号，无视值是否重复（如 1,2,3） -
dense_rank()：适合“并列不跳号”场景（如 1,1,2），但 BI 工具对它的下钻支持常不稳定，慎用
ORDER BY 必须写全，否则排名结果不可靠
窗口函数的 ORDER BY 不是可选项，而是决定排名逻辑的唯一依据。漏写或只写部分字段，会导致同一组内排序随机，尤其在数据量大、有并行执行的数据库（如 Redshift、Doris）中更明显。
典型现象：刷新看板时，同一用户的排名忽高忽低；导出 Excel 后发现名次和界面上不一致。
- 错误写法：
ROW_NUMBER() OVER (PARTITION BY region)—— 缺少ORDER BY，数据库自行决定顺序 - 正确写法：
ROW_NUMBER() OVER (PARTITION BY region ORDER BY revenue DESC, created_at ASC) - 注意：
created_at ASC是防并列兜底，避免因时间精度丢失导致排序不确定
WHERE 和窗口函数的执行顺序搞反了，排名就全错了
SQL 执行顺序中，WHERE 在窗口函数计算之前就已过滤数据。想“先算全量排名，再筛前 10”，不能靠 WHERE rank 写在主查询里——那会报错，因为 <code>rank 是计算字段，不在 WHERE 可见范围内。
BI 工具里常有人把窗口函数写进视图或 CTE，但前端又加了额外筛选条件，结果排名基准悄悄变了，自己却没察觉。
- 必须用子查询或 CTE 先算排名：
WITH ranked AS (SELECT *, ROW_NUMBER() OVER (ORDER BY sales DESC) AS rn FROM orders ) SELECT * FROM ranked WHERE rn <= 10 - 别在仪表盘里对含窗口函数的字段做“动态过滤”——Power BI 的“视觉对象级筛选”会重算上下文，可能让
rn值失效 - 如果要用参数化 TOP N（比如用户选“前 5 / 前 20”），得把 N 提前传入 SQL，而不是靠前端过滤
MySQL 8.0+ 和 PostgreSQL 的兼容性细节不能忽略
虽然主流数据库都支持标准窗口函数，但 MySQL 在 8.0 之前完全不支持，而很多遗留 BI 系统还连着老版本 MySQL。强行迁移 SQL 时，OVER() 语法会直接报错，不是性能问题，是语法错误。
另一个坑是 PostgreSQL 对空值的默认排序行为（NULLS LAST），而某些 BI 工具生成的 SQL 默认不显式声明，导致 NULL 销售额被排在最前面，拉低真实 Top 排名。
- MySQL 5.7 及更早：只能用变量模拟排名，但并发查询下结果不可靠，
@row := @row + 1在 BI 定时任务中极易出错 - PostgreSQL 中务必显式写：
ORDER BY revenue DESC NULLS LAST - ClickHouse、Doris 等 OLAP 引擎对
PARTITION BY字段类型敏感，字符串分区比数字分区慢 2–3 倍，影响看板加载
动态排名看着简单，真正卡住人的从来不是语法，而是它和 BI 渲染周期、缓存策略、前端筛选之间的隐式耦合。尤其是当报表要支持“按地区切换 + 按时间滑动 + 按指标排序”三重动态时，窗口函数的 PARTITION BY 和 ORDER BY 组合稍有偏差，整个排名逻辑就垮了。
