rank()与dense_rank()根本区别在于并列时是否跳过后续名次：rank()跳过（如1,1,3），dense_rank()不跳（如1,1,2）；二者均须配合over(order by)使用，缺order by则排名失效。
为什么 RANK 和 DENSE_RANK 在视图里结果总不对
根本原因不是函数写错了，而是没加 ORDER BY 子句——这两个函数必须配合 OVER() 中的 ORDER BY 才能产生有意义的排名。视图定义中漏掉它，会导致排序依据缺失，结果看似“随机”或全为 1。
另外，视图本身不保存数据，也不固化执行顺序，所以 RANK() 的行为完全取决于查询时的 OVER() 表达式，而不是建视图时的上下文。
- 必须写成
RANK() OVER (ORDER BY score DESC)，不能只写RANK() OVER () - 如果视图里要支持多种排序（比如按时间、按分数、按姓名），得把排序字段作为参数化入口——但 SQL 标准视图不支持参数，只能靠外部查询覆盖
OVER子句 - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 和旧版 MySQL 不支持窗口函数，建视图会直接报错
near "OVER": syntax error
RANK 和 DENSE_RANK 在视图里的行为差异怎么体现
区别只在并列后的跳号逻辑，和是否在视图里无关，但在聚合或后续过滤时影响明显。比如两人同分 95 分：
-
RANK()给两人都是 1，下一个不同分的人是 3（跳过 2） -
DENSE_RANK()给两人都是 1，下一个不同分的人是 2（不跳） - 如果视图用于生成“前 5 名榜单”，用
RANK()可能实际返回 7 行（因并列挤占名额），而DENSE_RANK()更贴近“去重后 Top 5”的直觉
示例（PostgreSQL）：
CREATE VIEW exam_ranking AS
SELECT name, score,
RANK() OVER (ORDER BY score DESC) AS rank_r,
DENSE_RANK() OVER (ORDER BY score DESC) AS rank_d
FROM students;
在视图中用 RANK 做分组内排名要注意什么
常见需求是“每科成绩的班级内排名”，这时必须加 PARTITION BY，否则算的是全局排名。漏掉它，视图看起来没错，但业务语义全错。
- 正确写法：
RANK() OVER (PARTITION BY subject ORDER BY score DESC) -
PARTITION BY字段必须来自视图 SELECT 列表，否则外部查询无法对齐分组（比如视图没选subject，却在OVER里分区，会报错或隐式忽略） - 性能上，
PARTITION BY字段如果有索引（如(subject, score)复合索引），排序开销明显降低；否则大表上可能触发临时文件排序 - 注意 NULL 值：默认
NULLS LAST（多数数据库），若字段含空分，可能被排到最后，影响“有效成绩排名”逻辑
视图里用 RANK 后，WHERE 条件不能直接过滤排名值
这是最常踩的坑：WHERE rank_r 在视图定义里直接写会报错，因为窗口函数不能出现在视图的 <code>WHERE 或 GROUP BY 中——它属于 SELECT 阶段计算，晚于 WHERE 执行。
- 正确做法：建好视图后，在外部查询中再过滤，例如
SELECT * FROM exam_ranking WHERE rank_r - 如果想封装成“可直接取 Top 3 的视图”，得用 CTE 或内联子查询，标准视图做不到
- 某些数据库（如 PostgreSQL）允许在视图里套一层子查询来绕过，但可读性和维护性变差，不推荐
真正容易被忽略的是：一旦视图被多个下游应用引用，每个调用方都得记得加这层外包装查询，否则排名字段只是摆设。
