根本原因是视图中order by未用唯一列兜底且调用时未强制排序，导致row_number()编号不可复现；必须补唯一列如id、显式处理null、将where下推至内层，并在调用时加order by rn。
视图里用 ROW_NUMBER() 分页出现重复，根本原因不是函数本身不稳，而是视图定义没锁住排序逻辑——只要 ORDER BY 不够唯一、或外层调用时没强制应用排序，数据库就可能每次按不同物理顺序编号。
ORDER BY 缺少唯一列兜底，编号结果不可复现
视图定义里如果只写 ORDER BY created_at DESC，而表中存在大量相同时间戳的记录，数据库没有义务保证这些行的相对顺序稳定。哪怕索引存在，优化器也可能因统计信息变化、并行计划切换等原因改变内部扫描顺序，导致同一视图反复查询时 ROW_NUMBER() 给出不同编号。
- 必须补上唯一列，例如
ORDER BY created_at DESC, id DESC或ORDER BY status, updated_at DESC, id - 不要依赖主键自动隐式排序：即使
id是主键，ORDER BY created_at仍会打破其天然顺序 - MySQL 8.0+ 和 PostgreSQL 支持
NULLS LAST，但若created_at允许为空，得显式写ORDER BY created_at DESC NULLS LAST, id DESC，否则 NULL 行位置浮动
视图未强制排序，调用方丢失 ORDER BY 语义
SQL 标准规定：视图本身不保存排序行为，ORDER BY 在视图定义中仅用于窗口函数（如 ROW_NUMBER()），不能保证最终结果有序。如果外部查询直接 SELECT * FROM my_view，不带 ORDER BY，数据库可返回任意顺序——这时你看到的“重复”，其实是两次查询取到了不同编号的行。
- 视图里
ROW_NUMBER() OVER (ORDER BY ...)只管编号，不管输出顺序 - 调用视图时必须显式加
ORDER BY rn，否则rn = 42这行未必出现在第 42 位 - 别在视图里写
ORDER BY rn—— 视图不允许顶层ORDER BY（SQL Server 报错，PostgreSQL 忽略，MySQL 5.7 允许但无效）
WHERE 条件写在视图外，破坏了编号上下文
常见错误是把过滤条件放在视图调用侧，比如视图定义为 SELECT *, ROW_NUMBER() OVER (ORDER BY x) AS rn FROM t，然后外面写 SELECT * FROM v WHERE x = 'A' AND rn BETWEEN 10 AND 20。这会导致：先全表编号，再过滤，编号范围错乱，且无法利用索引下推。
- 正确做法是把业务过滤提前到视图内，或用参数化 CTE 替代视图
- 如果必须动态过滤，改用内联表值函数（TVF）或带参数的 CTE，确保
WHERE在ROW_NUMBER()计算前生效 -
rn BETWEEN @start AND @end必须和OVER(ORDER BY ...)的索引完全对齐，否则引擎可能放弃索引排序，退化成 Sort 算子
最易被忽略的一点：视图一旦创建，其执行计划就固化在元数据里，后续表结构变更（如新增索引、修改字段类型）不会自动刷新视图缓存。哪怕你补了 id 到 ORDER BY，若没重建视图或清空计划缓存，旧计划仍可能沿用无序扫描路径。
